Re: Add CREATE support to event triggers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE support to event triggers
Date: 2014-01-10 18:17:53
Message-ID: CA+Tgmobw1gcaV4NwsZ+aPZzc1WTjUFhJjYmT8OE_f+RFVo+x7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> That's project policy
>> and always has been. When somebody implements 50% of a feature, or
>> worse yet 95% of a feature, it violates the POLA for users and doesn't
>> always subsequently get completed, leaving us with long-term warts
>> that are hard to eliminate.
>
> So why was project policy violated when we released 9.3 with only DROP
> event support? Surely that was a worse violation of POLA than my
> suggestion?

Well, obviously I didn't think so at the time, or I would have
objected. I felt, and still feel, that implementing one kind of event
trigger (drop) does not necessarily require implementing another kind
(create). I think that's clearly different from implementing either
one for only some object types.

"This event trigger will be called whenever an object is dropped" is a
reasonable contract with the user. "This other event trigger will be
called whenever an object is created, unless it happens to be a
schema" is much less reasonable.

At least in my opinion.

--
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-01-10 18:23:21 Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Previous Message Robert Haas 2014-01-10 18:11:32 Re: dynamic shared memory and locks