Re: Patch for 8.5, transformationHook
От | Pavel Stehule |
---|---|
Тема | Re: Patch for 8.5, transformationHook |
Дата | |
Msg-id | 162867790908092325h20b264a4n8a30eac04eb6fa65@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch for 8.5, transformationHook (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
2009/8/9 Jeff Davis <pgsql@j-davis.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 > >
В списке pgsql-hackers по дате отправления: