On Wed, Mar 26, 2008 at 08:31:04AM -0400, Andrew Dunstan wrote: > David Fetter wrote: >> Folks, >> >> Neil Conway sent me a patch that sketched out a plan to make quals >> visible to functions >> > er, what? Please explain what this means, why it might be useful. > Example(s) would help.
Right now, user-callable code has no way to access the predicates of the query which calls it. Neil's patch was intended to expose some of them. The biggest use cases I see are for inter-database communication such as dblink and friends. The dblink part of the patch shows what's supposed to be happening. What happens now with dblink is that the remote table (more generally, the output of a fixed query) gets materialized into memory in its entirety, and if it's bigger than what's available, it will crash the backend or worse. That happens because functions do not have any access to the predicates with which they were called, so the current workaround is to pass the predicates manually and then cast. Speaking of casting, how hard would it be to make something like this work? SELECT foo, bar, baz FROM function_returning_setof_record('parameters','here') AS f(compound_type); >> * In PL/Perl, $_TD->{_quals} gets the qualifiers, but they really >> should go in their own variable. I'm thinking that one should be >> called $_QUAL. > > $_TD is only there for triggers. Is this a trigger feature? Clearly it is not, but the procedure for adding a new variable which needs to be available to functions is far from clear, so Korry decided to wedge it into that existing variable to get a proof of concept out the door. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers