Hello 2009/7/30 Robert Haas <robertmh...@gmail.com>: > On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule<pavel.steh...@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. Pavel > > 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. > > ...Robert > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
