On Sun, Nov 22, 2009 at 11:38 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >>> CREATE IF NOT EXISTS has been proposed and rejected before, more than >>> once. Please see the archives. > >> Search for CINE to find the discussions. This is a good place to start: >> http://archives.postgresql.org/pgsql-hackers/2009-05/msg00252.php > >> Despite Tom's assertions to the contrary, I am unable to find a clear >> consensus against this feature in the archives, > > I think you didn't look back far enough --- that issue was settled years > ago. IIRC the killer argument is that after CINE you do not know the > state of the object: it exists, yes, but what properties has it got? > If it already existed then it's still got its old definition, which > might or might not be what you're expecting. > > CREATE OR REPLACE has got far safer semantics from the viewpoint of a > script that wants to bull through without having any actual error > handling (which is more or less the scenario we are arguing here, no?) > After successful execution of the command you know exactly what > properties the object has got. Sure. I think that CINE only makes sense for objects for which COR can't be implemented - things that have internal substructure, like tables or tablespaces. I agree that there are pitfalls for the unwary but I still think it's better than nothing. I understand that you disagree. > Whether it would be sensible to have CREATE OR REPLACE semantics for a > language is something I'm not very clear on. It seems like changing any > of the properties of a pg_language entry could be rather fatal from the > viewpoint of an existing function using the language. > > [ thinks for awhile... ] Actually, CREATE LANGUAGE is unique among > creation commands in that the common cases have no parameters, at least > not since we added pg_pltemplate. So you could imagine defining CINE > for a language as disallowing any parameters and having these semantics: > * language not present -> create from template > * language present, matches template -> OK, do nothing > * language present, does not match template -> report error > This would meet the objection of not being sure what the state is > after successful execution of the command. It doesn't scale to any > other object type, but is it worth doing for this one type? CREATE OR REPLACE seems like a better fit in this case. For example, it seems plausible that someone might want to add an inline handler to a procedural language that didn't have one without dropping and recreating the language. Even changing the call handler seems like it could be potentially useful in an upgrade scenario. ...Robert -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
