Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
