From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndQuadrant.com>
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: Thu, 17 Jan 2013 22:51:03 +0100
Message-ID: <m2hamfcwc8.fsf@2ndQuadrant.fr> (raw)
In-Reply-To: <16675.1358454278@sss.pgh.pa.us>
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>
<CA+TgmobfeB_YpgMv5NjW52tG36Hg_DY=jq0XDkE5zwCstPQ4pg@mail.gmail.com>
<m2pq14m7sx.fsf@2ndQuadrant.fr>
<CA+TgmoYEW583z+oisToCYQMz2grzpavdXrCi3-W2D_+nucVhzQ@mail.gmail.com>
<CA+U5nM+Uuh7cyHSJ5wN54twBUGSncJzqpZB83xuZw4VP7UCziQ@mail.gmail.com>
<16675.1358454278@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I have to completely disagree with that. If we don't want PostgreSQL
> to soon subside into an unfixable morass, as I think Brooks puts it,
> we must *not* simply patch things in a way that expediently provides
> an approximation of some desired feature. We have to consider, and put
> substantial weight on, having a clean and maintainable system design.
When in Ottawa next may, I will have to buy you a glass of your favorite
wine and explain to you my main use case and vision. You will then
realize that all this time that I've been spending on Event Triggers is
a sideway to build something else entirely, because I know that it's the
only way to get the feature I want in core PostgreSQL.
So yes, I know about the clean and maintainable system design
constraint. I've a lot to learn still, and I appreciate your help very
much. Rest assured that the path you describe is the one I'm taking.
> I think that we're not realistically going to be able to introduce
> event triggers in very many of the places we'd like to have them
> without first doing a lot of fundamental refactoring.
We're only talking about ddl_command_start and ddl_command_end now. The
table_rewrite event is still on the horizon, but is not realistic to get
in 9.3 anymore, I think :(
So we're talking about adding some call points only in utility.c, only
before or after a ddl command is run, including nested sub-commands.
> So my opinion is that most of what we'd like to have here is material
> for 9.4 or 9.5 or even further out. If we can get the event trigger
> catalog infrastructure and some *very* basic events, like
> end-of-toplevel-command, into place for 9.3, we'll have done well.
My feeling is that I'm sending patches that only implement the *very*
basic events here, and nothing more. Most of the heat of this thread
came from a discussion about a feature that's very hard to design and
that is not in my patch series to review.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
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: dimitri@2ndQuadrant.fr, tgl@sss.pgh.pa.us, simon@2ndQuadrant.com, robertmhaas@gmail.com, alvherre@2ndQuadrant.com
Subject: Re: Event Triggers: adding information
In-Reply-To: <m2hamfcwc8.fsf@2ndQuadrant.fr>
* 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