Re: Patch for 8.5, transformationHook

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-08-09 02:21:48
Message-ID: 1249784508.9256.892.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message marcin mank 2009-08-09 02:41:38 Re: Fixing geometic calculation
Previous Message Robert Haas 2009-08-09 02:02:11 Re: hot standby - merged up to CVS HEAD