Skip site navigation (1) Skip section navigation (2)

Re: Patch for 8.5, transformationHook

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch for 8.5, transformationHook
Date: 2009-07-30 04:01:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

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.

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: Pavel StehuleDate: 2009-07-30 05:22:04
Subject: Re: Patch for 8.5, transformationHook
Previous:From: Tom LaneDate: 2009-07-30 03:33:05
Subject: Re: question about the _SPI_save_plan() and plan cache

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group