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
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 |