From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Event Triggers: adding information
Date: Wed, 16 Jan 2013 18:14:41 -0500
Message-ID: <4717.1358378081@sss.pgh.pa.us> (raw)
In-Reply-To: <m2ehhkrfqk.fsf@2ndQuadrant.fr>
References: <m2txrsdzxa.fsf@2ndQuadrant.fr>
<m2zk1j9c44.fsf@2ndQuadrant.fr>
<CA+Tgmob6kmAySE5yXvd3uE9LifHunufMg9iU3GmbJ5bpGPiHjQ@mail.gmail.com>
<m2k3sbe51z.fsf@2ndQuadrant.fr>
<CA+TgmoZjOACnHOKrz-eucj3FJXrYJzA-_yjSqajOQR8qkjCi=w@mail.gmail.com>
<m2bodi55yn.fsf@2ndQuadrant.fr>
<CA+TgmoZTxXGAkoyQD0aNOyju1X19SnVfk7KV9fsJCv63bS-C4g@mail.gmail.com>
<m27go1ot1a.fsf@2ndQuadrant.fr>
<20130104205251.GB9191@alvh.no-ip.org>
<m28v88pqin.fsf@2ndQuadrant.fr>
<20130109165829.GB4490@alvh.no-ip.org>
<CA+TgmobykpymdGyfbCDEfS6+-50X-AKYTdK88fjMS4-mY5SBdw@mail.gmail.com>
<m2ehhkrfqk.fsf@2ndQuadrant.fr>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> There's a difference between "it's not the way I would have done it" and
> "the author didn't think about what he's doing". That's also the reason
> why it's very hard to justify sending a polished enough patch as a non
> commiter.
> And then this patch is like the next one in a long series that is
> lasting for about 2 years now, and spliting it is just more work for
> everybody, and then you take the risk that the next commiter who looks
> at the patch prefers to see a complete enough view of the goal you're
> trying to reach.
What was discussed at the last dev meeting was assigning a committer to
each large patch to start with, which would reduce the risk of the
goalposts moving that way. It seems to me that Robert's at least
unofficially taken that role for event triggers. You should be happy,
because if I were reviewing it I'd likely bounce the whole thing.
I'm not convinced this will *ever* be a stable feature that doesn't
create more problems than it fixes.
> What I think you're missing here is the proposal flying around to have
> drop operation get back to ProcessUtility so that C hooks and event
> triggers both can have at it.
I've seen no such proposal, and it seems like a nonstarter just from the
idea. dependency.c doesn't have a syntax tree to describe each object
that it finds to drop; creating one, and then doing a lookup to re-find
the object, is just going to make drops hugely slower and buggier. Not
to mention the large amount of code that would have to be added and
maintained. Not to mention that the objects dependency.c works with
aren't necessarily all that interesting from the user's level --- for
instance, do you really want to see each column default expression
dropped individually? Not to mention that the permissions
considerations are different from a standalone DROP.
The bigger picture there is that it's taken us years, and multiple major
iterations, to get cascaded drops to work properly and reliably. I'm
disinclined to rip that code open and rewrite it completely; let alone
add hooks that might inject random operations at any point in the
process.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, dimitri@2ndQuadrant.fr, robertmhaas@gmail.com, alvherre@2ndquadrant.com
Subject: Re: Event Triggers: adding information
In-Reply-To: <4717.1358378081@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox