"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.
regards, tom lane