On Tue, May 5, 2009 at 8:56 AM, Andrew Dunstan <andrew@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
