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

On 2014-11-07 21:41:17 -0500, Robert Haas wrote:
> 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

I don't understand why this is particularly difficult to regresssion
test. It actually is comparatively simple?

> and which will likely receive very limited
> testing from users to support a feature that is not in core,

Just like half of the features you worked on yourself lately? Why is
this an argument?

Being able to replicate DDL is a feature wish that has been around
pretty much since the inception of trigger based replication
solution. It's not some current fancy. And the json stuff only got there
because people wanted some way to manipulate the names in the replicated
- which this abstraction provides them with.

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

You're just as much to blame for not writing a general json abstraction
layer for EXPLAIN. I'd say that's not much blame, but still, there's
really not much difference there.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services