Re: Add CREATE support to event triggers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Add CREATE support to event triggers
Date
Msg-id CA+Tgmoaq+x48h42RRBwADrGQ_ukhkLvoYjyLwqm86-C8F4j0VQ@mail.gmail.com
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Add CREATE support to event triggers  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum
Next
From: Robert Haas
Date:
Subject: Re: [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace