Re: Add CREATE support to event triggers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE support to event triggers
Date: 2014-11-08 02:41:17
Message-ID: CA+Tgmoaq+x48h42RRBwADrGQ_ukhkLvoYjyLwqm86-C8F4j0VQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-08 02:47:30 Re: BUG #11867: Strange behaviour with composite types after resetting database tablespace
Previous Message Robert Haas 2014-11-08 02:21:22 Re: Proposal: Log inability to lock pages during vacuum