Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If it did so, that would be outside the apparent meaning of the
> command, which is to do nothing if an object of that name exists.
> That's why we've gone with CREATE OR REPLACE instead.
I think that "fail on existence of an object conflicting with given
definition" is behavior which could be documented and rates fairly
low on my astonishment scale. (I can't speak for anyone else.)
I am skeptical that, in the absence of built-in support for checking
the existing object against the supplied definition, people would
generally go any further than Andrew's example. When they did, I'm
skeptical about how often they would get the details exactly right.
> Yes, I'd expect the user to custom-code it, because it's not clear
> exactly which properties the script would be depending on and which
> ones it's okay to allow to vary. To take just one example, is it
> okay if the object ownership is different from current user? That
> might be fine, or it might be catastrophic (suppose the script is
> going to issue GRANT commands that presuppose particular ownership;
> if it's different you could be left with security holes).
Yeah, that's an area which I figured would require some discussion.
The best behavior isn't immediately clear to me in that regard. I
didn't figure that arriving at some decision on that was necessarily
an insurmountable obstacle. Similar issue with indexes, although the
answer there seems clearer (at least to me).
> (I agree that CREATE OR REPLACE on a table might be expected to
> destroy existing data, but we don't have such a command and there is
> no proposal to make one.)
There was, up-thread, discussion by multiple people of the desire to
have CINE for tables. Andrew's example was specifically about an
alternative way of spelling that. This branch of the thread has been
all about exactly that. (Well, at least in my head.) You asserted
that CREATE OR REPLACE was superior to CINE; I took it to be in
response to the discussion of CINE for tables, but I guess it was
just in the scope of languages. Sorry for misinterpreting.
-Kevin
