Re: Patch for 8.5, transformationHook

On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
> Hello
>
> 2009/7/25 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> 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
>>>> 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.

Sure, post it and let's discuss.

...Robert