Re: Patch for 8.5, transformationHook

On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2009/7/30 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)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.

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