On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2009/4/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> 2009/4/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>>> No, I was complaining that a hook right there is useless and expensive.
>>>> transformExpr() is executed multiple times per query, potentially a very
>>>> large number of times per query; so even testing to see if a hook exists
>>>> is not a negligible cost.
>>> I did some tests based on pgbench.
>> The queries done by pgbench are completely trivial and do not stress
>> parser performance. Even if they did (consider cases likw an IN with a
>> few thousand list items), the parser is normally not a bottleneck
>> compared to transaction overhead, network round trips, and pgbench
>>> I though about different position of hook, but only in this place the
>>> hook is useful (because expressions are recursive).
>> As I keep saying, a hook there is useless, at least by itself. You
>> have no control over the grammar and no ability to modify what the
>> rest of the system understands. The only application I can think of is
>> to fool with the transformation of FuncCall nodes, which you could do in
>> a much lower-overhead way by hooking into transformFuncCall. Even that
>> seems pretty darn marginal for real-world problems.
> I am sending modified patch - it hooking parser via transformFuncCall
I am reviewing this patch. It seems to me upon rereading the thread
that the objections Tom and Peter had to inserting a hook into
transformExpr() mostly still apply to a hook in transformFuncCall():
namely, that there's no proof that putting a hook here is actually
useful. I think we should apply the same criteria to this that we
have to some other patches that have been rejected (like the
extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely,
requiring that the extension mechanism be submitted together with at
least two examples of how it can be used to interesting and useful
things, bundled as one or more contrib modules.
There is some discussion on this thread of things that you think that
this patch can be used to do, but I think it would be much easier to
see whether it's (a) possible and (b) not too ugly to do those things
if you reduce them to code.
In response to
pgsql-hackers by date
|Next:||From: Jaime Casanova||Date: 2009-07-25 21:38:25|
|Subject: Re: ECPG dynamic cursor, SQLDA support|
|Previous:||From: Bernd Helmle||Date: 2009-07-25 20:58:27|
|Subject: Re: Shouldn't psql -1 imply ON_ERROR_STOP?|