Re: Patch for 8.5, transformationHook

2009/8/9 Jeff Davis <pgsql(at)j-davis(dot)com>:
> 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

gram.y is hard limit of everything what we can do in parser. I thing
so there is possible mix two grams together (like enterprisedb do it -
integration plpgsql), but still first gram has to have some static
entry points - we can't do define new keyword and cannot define new
rules, because all is hardly static. It is bison limit. And without
changes parser's engine we cannot do some more.

I see some possibility in future - to add some like preprocessor for
main parser, or postprocessor (for badly processed statements). These
creatures allows to define new SQL statement pseudo integrated to
core. But this is different task absolutely independent to function
transformation hook.

But I don't thing so this is real limit. Really I don't would to
create new SQL statements now. With hook I am able to work with param
list and named param list. This allows lot of games over standard
function syntax.

>
> 2. Tom Lane is concerned about multiple hooks working together:
>
> http://archives.postgresql.org/pgsql-hackers/2009-04/msg01038.php
>

with well written hooks it isn't problem. You can check sample hooks
together. I agree, so bad hook can be wrong, but this is general
problem of all hooks in postgresql (all hooks in the world).

> 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?
>

If somebody find any general solution different than hook I for it.

> * 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.
>

Some XML functions (not all) and COALESCE should be refactorized. But
the range for hook is external modules. It's same like executor hooks
or some other hooks in PostgreSQL. It's more readable to use direct
access to code than hooks when it's possible.

> 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.
>

ok I agree.

Pavel

> 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
>
>