Re: Patch for 8.5, transformationHook - Mailing list pgsql-hackers

2009/8/4 Robert Haas <robertmhaas@gmail.com>:
> On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehule<pavel.stehule@gmail.com> wrote:
>> 2009/7/30 Robert Haas <robertmhaas@gmail.com>:
>>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule<pavel.stehule@gmail.com> wrote:
>>>> 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.
>>>
>>> These are pretty good examples, but the whole thing still feels a bit
>>> grotty to me.  The set of syntax transformations that can be performed
>>> with a hook of this type is extremely limited - in particular, it's
>>> the set of things where the parser thinks it's valid and that the
>>> structure is reasonably similar to what you have in mind, but the
>>> meaning is somewhat different.  The fact that two of your three
>>> examples require your named and mixed parameters patch seems to me to
>>> be evidence of that.
>>>
>>
>> I see the main hook using as open door to functionality like decode
>> and json. Anotation is little bit corner use case. We don't need a
>> change of syntax or rules in parser. But I need to get some info for
>> functions from parser stage - like JSON or replace standard coercion
>> rules like decode. Hook is the most simple and general technique for
>> it (what I found). I thing, so there are other techniques - but it
>> needs more invasive patch and are not too general - what is values of
>> any hooking.
>>
>> I doesn't thing, so there will be any real extended parser based on
>> bison in near or far future. I thing, so this is theoretically
>> possible, but nobody work on it. What more - with extensible parser we
>> still need the transformation hook, because we need the change in
>> transformation - decode, json.
>>
>>> The JSON transformation provides functionality which is very similar
>>> to what we also offer for XML.  I sort of think we ought to just
>>> provide that, rather than making it an add-on.  I have found it to be
>>> a tremendously attractive alternative to XML.
>>
>> The JSON is only one use case (there should be output to any format),
>> and I agree, so this should be in core. But every integration similar
>> function to core needs one or two years. Hook allows do this things
>> faster and from external library. It's little bit lighter process to
>> put your project to pgfoundry than to PostgreSQL core.
>
> I don't really believe that JSON is "only one use case".  XML and JSON
> are in a class of their own; there's nothing else out there that is
> really comparable.

XML and JSON are well known formats. But everybody can use it for
custom formats, for binary formats, for direct communication, for
loging, ...

Pavel

>
> So I guess I'm back to feeling like this is of pretty marginal
> benefit.  But I would still like some opinions from others.
>
> ...Robert
>