On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> writes: > > On Thu, Oct 30, 2008 at 05:16, Tom Lane <[EMAIL PROTECTED]> 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 <[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
