Re: pre-MED

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