Re: Add CREATE support to event triggers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Add CREATE support to event triggers
Дата
Msg-id CA+Tgmoaq+x48h42RRBwADrGQ_ukhkLvoYjyLwqm86-C8F4j0VQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add CREATE support to event triggers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Add CREATE support to event triggers  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Michael Paquier wrote:
>
>> Here are more thoughts among those lines looking at the current state of
>> the patch 4 that introduces the infrastructure of the whole feature. This
>> would make possible in-memory manipulation of jsonb containers without
>> relying on a 3rd-part set of APIs like what this patch is doing with
>> ObjTree to deparse the DDL parse trees.
>
> Thanks for the thoughts.  I have to say that I have no intention of
> reworking the jsonb code.  If somebody else wants to do the legwork and
> add that API as you suggest, I'm happy to remove all the ObjTree stuff
> from this patch.  I don't expect this to happen too soon, though, so I
> would instead consider committing this patch based on ObjTree.  Later,
> when somebody comes around to reworking jsonb, we can rip ObjTree out.
>
>> This infrastructure would allow in-memory manipulation of jsonb containers.
>> Containers that can then be easily be manipulated to be changed back to
>> strings and for value lookups using key strings.
>
> Honestly, I had hoped that the jsonb code would have already included
> this kind of functionality.  I wasn't too happy when I discovered that I
> needed to keep the ObjTree crap.  But I don't want to do that work
> myself.

If we're going to have infrastructure for this in core, we really
ought to make the effort to make it general instead of not.

I still think this whole idea is a mess.  It adds what looks to be a
LOT of code that, at least as I understand it, we have no compelling
way to regression test and which will likely receive very limited
testing from users to support a feature that is not in core, may never
be, and which I strongly suspect may be too clever by half.  Once
you've committed it, you're going to move onto other things and leave
it to everyone who comes after to try to maintain it.  I bet we'll
still be running into bugs and half-implemented features five years
from now, and maybe in ten.  Ramming through special-purpose
infrastructure instead of generalizing it is merely icing on the cake,
but it's still moving in the wrong direction.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace