2009/8/10 Tom Lane <t...@sss.pgh.pa.us>: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule<pavel.steh...@gmail.com> >> wrote: >>> new patch add new contrib "transformations" with three modules >>> anotation, decode and json. > >> 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 finally got around to looking at these examples, and I still don't > find them especially compelling. Both the decode and the json example > could certainly be done with regular function definitions with no need > for this hook.
please, show it. regards Pavel Stehule The => to AS transformation maybe not, but so what? > The reason we don't have that one in core is not technological. > > The really fundamental problem with this hook is that it can't do > anything except create syntactic sugar, and a pretty darn narrow class > of syntactic sugar at that. Both the raw parse tree and the transformed > tree still have to be valid within the core system's understanding. > What's more, since there's no hook in ruleutils.c, what is going to come > out of the system (when dumping, examining a view, etc) is the > transformed expression --- so you aren't really hiding any complexity > from the user, you're just providing a one-time shorthand that will be > expanded into a notation he also has to be familiar with. > > Now you could argue that we've partly created that restriction by > insisting that the hook be in transformFuncCall and not transformExpr. > But that only restricts the subset of raw parse trees that you can play > with; it doesn't change any of the other restrictions. > > Lastly, I don't think the problem of multiple hook users is as easily > solved as Pavel claims. These contrib modules certainly fail to solve > it. Try unloading (or re-LOADing) them in a different order than they > were loaded. > > So on the whole I still think this is a solution looking for a problem, > and that any problems it could solve are better solved elsewhere. > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
