Re: Patch for 8.5, transformationHook - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Patch for 8.5, transformationHook
Date
Msg-id 1249784508.9256.892.camel@jdavis
Whole thread Raw
In response to Re: Patch for 8.5, transformationHook  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Patch for 8.5, transformationHook  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Patch for 8.5, transformationHook  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Sun, 2009-07-26 at 15:29 +0200, Pavel Stehule 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.

This is not a complete review of the patches, but I have read through
the discussion and taken a brief look at the code from a use-case point
of view (not a technical review).

My general feeling for the use case of the patch is positive. Pavel
showed a reasonable variety of valid use cases, and the possibility to
make existing special cases (like XML) no longer special cases.

However, there are causes for concern:

1. Robert Haas is concerned that the kind of transformations allowed
might be too limited:

http://archives.postgresql.org/pgsql-hackers/2009-07/msg01947.php

2. Tom Lane is concerned about multiple hooks working together:

http://archives.postgresql.org/pgsql-hackers/2009-04/msg01038.php

3. All throughout the thread, there is a general concern that this might
not be exactly the right solution.

I think we need to wait on this patch. Waiting will hopefully provide
better answers to the following questions:

* What other similar features exist in the SQL spec that require a
similar special case now? If we added this hook, would those still
require a special case?

* Can anyone think of a better hook or API change that would answer
these use cases?

* Can anyone think of other features that almost fit this model, but
that the hook won't quite work for?

* If the hook can implement XML, should we refactor the XML support (and
COALESCE, etc.) to use the hook for the sake of consistency? If the hook
is not good enough for those features, that might indicate a problem.

Considering that the next commitfest is only about a month away, I don't
think that it is too much of a burden to wait.

I didn't have time to do a complete review, so I can't provide much
better direction than this right now.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: hot standby - merged up to CVS HEAD
Next
From: marcin mank
Date:
Subject: Re: Fixing geometic calculation