Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule<pavel.stehule@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. 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
