Re: Add CREATE support to event triggers

On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 10 January 2014 15:48, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> On 8 January 2014 20:42, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>>>
>>>> CREATE SCHEMA IF NOT EXISTS "some schema" AUTHORIZATION "some guy";
>>>
>>> Hmm, given in 9.3 it was OK to have only DROP event triggers, I think
>>> it should be equally acceptable to have just CREATE, but without every
>>> option on CREATE. CREATE SCHEMA is easily the most complex thing here
>>> and would be the command/event to deprioritise if we had any issues
>>> getting this done/agreeing something for 9.4.
>>
>> I don't know that I agree with that, but I guess we can cross that
>> bridge when we come to it.
>
> We've come to it...
>
> You would prefer either everything or nothing?? On what grounds?

I hardly think I need to justify that position. 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. It's perfectly fine to implement a
feature incrementally if the pieces are individually self-consistent
and ideally even useful, but deciding to support every command except
one because the last one is hard to implement doesn't seem like a
principled approach to anything. It's not even obvious to me that
CREATE SCHEMA is all that much harder than anything else and Alvaro
has not said that that's the only thing he can't implement (or why) so
I think it's entirely premature to make the decision now about which
way to proceed - but, OK, sure, if you want to force the issue now,
then yeah, I think it's better to have everything or nothing than to
have support for only some things justified by nothing more than
implementation complexity.

Aside from the general issue, in this particular case, I have
previously and repeatedly expressed concerns about regression test
coverage and suggested a path that would guarantee thorough regression
testing but which would require that support be complete for
everything present in our regression tests. Although there may be
some other plan for guaranteeing thorough regression testing not only
now but going forward, I have not seen it proposed here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company