Re: Patch for 8.5, transformationHook

Hello

note about SQL:201x
http://blogs.mysql.com/peterg/2009/06/07/soothsaying-sql-standardization-stuff/

regards
Pavel Stehule

2009/7/26 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> Hello
>
> new patch add new contrib "transformations" with three modules
> anotation, decode and json.
>
> These modules are ported from my older work.
>
> Before applying this patch, please use named-fixed patch too. The hook
> doesn't need it, but modules anotation and json depend on it.
>
> Regards
> Pavel Stehule
>
> 2009/7/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> 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
>>
>