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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
