Re: Patch for 8.5, transformationHook

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@gmail.com>:
> On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehule<pavel.stehule@gmail.com> wrote:
>> 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.
>
> Sure, post it and let's discuss.
>
> ...Robert
>