Jan Wieck <[EMAIL PROTECTED]> writes:
> Actually I'm kicking around a slightly different idea, how to
> resolve the entire problem. We could build up the
> querystring, required to do the check, at trigger creation
> time, parse it and store the querytree node-print or hand it
> to the trigger as argument.
Hm. Seems kinda bulky; and the parse step alone is not that expensive.
(You could only do raw grammar parsing I think, not the parse analysis
phase, unless you wanted to deal with having to outdate these stored
querytrees after changes in table schemas.)
I think the existing scheme of generating the plan during first use
in a particular backend is fine. At least as long as we're sticking
with standard plans at all ... IIRC Stephan was wondering about
bypassing the whole parse/plan mechanism in favor of heap-access-level
operations.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
