Search Postgresql Archives

Re: Custom FDW - the results of a nested query/join not being passed as qual to the outer query

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Many thanks for the fast response. 

Using an SRF is an interesting idea, I'll have a play and see if we can make that work.

Cheers,
Kai

On Wed, Jan 27, 2021 at 3:27 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Kai Daguerre <kai@xxxxxxxxxx> writes:
> We often have virtual tables where a list operation is not viable/possible
> without providing quals. For example we have implemented a 'whois' table,
> which will retrieve whois information for specified domains. It is clearly
> not practical to do an unqualified 'list' of *all* domains.

In that case you're going to have to resign yourself to some queries
failing.  This is unavoidable, consider "select * from whois".  But
just because the query has a WHERE condition doesn't mean that a useful
restriction clause can be extracted for any particular table.

I think the best you can do is (1) fail at runtime if there's no qual
and (2) at plan time, return an extremely high cost estimate for a
qual-less scan, in hopes of discouraging the planner from choosing
that.  (Instead of (2), you could perhaps not generate a scan path
at all, but that's likely to lead to an unintelligible error message.)

Perhaps you should rethink whether you really want a foreign table
rather than a set-returning function.  With the SRF approach it's
automatic that the user must supply the restricting argument(s) you need.

                        regards, tom lane

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux