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

From Robert Haas
Subject Re: Add CREATE support to event triggers
Date
Msg-id CA+Tgmobw1gcaV4NwsZ+aPZzc1WTjUFhJjYmT8OE_f+RFVo+x7w@mail.gmail.com
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Add CREATE support to event triggers
List pgsql-hackers
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs <simon@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: dynamic shared memory and locks
Next
From: Robert Haas
Date:
Subject: Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL