On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote:
> "Alex Hunsaker" <badalex@gmail.com> writes:
> > On Thu, Oct 30, 2008 at 05:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Surely they all have a way to call a SQL function that returns text.
>
> > Sure but when you call that function you get *that* functions
> > qualifier. And unless there already is a way to grab the "parent"
> > query qualifiers, the PL specific hacks seem not so bad and very
> > similar to how we have to build trigger arguments for every PL
> > already.
>
> The PL hacks are awful :-(, not least because that path leads to
> randomly different syntax in each PL for exactly the same functionality.
>
> As I see it, there are two big problem areas in this patch:
> 1. How to get the information about restriction clauses to the place
> where we'd use it;
> 2. What to do with it once we've got it.
>
> We already went over #2 in some detail: the existing ruleutils.c code
> just isn't very suitable for this purpose. This could probably be
> worked around, eg drop restriction clauses that contain subplans or
> outer-relation variables; though I'm quite unsure about the issue of
> which names to use for the column variables.
>
> As for #1, the patch proposes to pass the Plan node (more or less, but
> that's the key thing) via a new field in ReturnSetInfo. The first
> problem with that is that it only makes the information available to
> set-returning functions occurring at the top level of a FunctionScan
> node. The second problem is that any layer of code we want to pass the
> information down through has to explicitly know about it, and we have
> to invent some new API for each one of those layers.
>
> ISTM that a saner way to approach this would be to set up a global way
> to find out "what's the currently executing Plan node?". Then this
> particular problem could be solved by just grabbing the qual field from
> that node. Infrastructure like that could be useful for instrumentation
> and debugging purposes as well. I'm not sure about the overhead
> involved, though. The obvious implementation would add three lines of
> code to ExecProcNode:
>
> PlanState *save_ActivePlanNode = ActivePlanNode;
>
> ActivePlanNode = node;
>
> ...
>
> ActivePlanNode = save_ActivePlanNode;
>
> which doesn't seem like it would amount to anything compared to the
> total execution of a plan node, but we do know that ExecProcNode
> is a hot spot in some usages.
Going with the ExecProcNode modification you're proposing, how big
would a minimal pre-MED patch be?
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