Re: Patch for 8.5, transformationHook

Hello

2009/7/25 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule<pavel.stehule@gmail.com> wrote:
>> 2009/4/18 Tom Lane <tgl@sss.pgh.pa.us>:
>>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>>> 2009/4/11 Tom Lane <tgl@sss.pgh.pa.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
>>> itself.
>>>
>>>> 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.

I have in my plan add to contrib JSON support similar to Bauman design:

http://www.mysqludf.org/lib_mysqludf_json/index.php

It's will be sample of "smart" functions. Because this need more then
less work I am waiting on commit.

Other simple intrduction contrib module should be real Oracle decode
function - I sent source code some time ago. But this code needs some
modification. I should send this code if you need it.

Pavel

>
> 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.
>
> ...Robert
>