On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 10 January 2014 15:48, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> On 8 January 2014 20:42, Alvaro Herrera <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
