On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan <and...@dunslane.net> wrote: > We have debated CREATE ... IF NOT EXISTS in the past, and there is no > consensus on what it should do, so we don't have it for any command. That is > quite a different case from what's being asked for, and the two should not > be conflated.
I must be missing something, because the semantics of CREATE ... IF NOT EXISTS seem pretty well-defined to me, at least for any object that has a name. Check whether that name is in use; if not, create the object per the specified definition. Now for something like ALTER TABLE ... ADD FOREIGN KEY I can see that there could be a problem. That having been said, it's certain that CREATE IF NOT EXISTS is a bigger foot-gun than DROP IF EXISTS, because after a succesful DROP IF EXISTS the state of the object is known, whereas after CREATE IF NOT EXISTS, it isn't (yes, it exists, but the definitions might not match). Still, that seems no reason not to implement it. Right now, I have a complex set of scripts which track the state of the database to determine which DDL statements have already been applied. Something like this would potentially simplify those scripts quite a bit, so I'm much in favor. On the other hand, I also agree with the point already made that these are two different features, and we may as well focus on one at a time. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
