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:
>> 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
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.
> With regard to the annotation transformation, if we're about to
> diverge from SQL:201x, do we want to rethink our oppostion to foo(bar
> => baz)? Just asking.
> I'm not dead set against this patch. But I'm not really sold either.
> I think we need some more input from other people.
In response to
pgsql-hackers by date
|Next:||From: Albe Laurenz||Date: 2009-07-30 07:13:17|
|Subject: Re: RFD: Don't force plpgsql IN parameters to constant |
|Previous:||From: Robert Haas||Date: 2009-07-30 04:01:46|
|Subject: Re: Patch for 8.5, transformationHook|