"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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers