Kai Daguerre <kai@turbot.com> 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.
