"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The argument against CINE is that it's unsafe.
> By no means rhetorically, is that based on the assumption that the
> statement would not validate that the existing object (if any) matches
> the supplied definition?
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.
>> The fragment proposed by Andrew is no safer, of course, but it could
>> be made safe by adding additional checks that the properties of the
>> existing object are what the script expects.
> Again, not rhetorically, is that assuming an error-free mapping of the
> CREATE statement to all the related system tables -- each time it is
> written by every user, individually?
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).
> Only with the most simplistic implementation of CINE. I really don't
> see how that assertion holds up if there is checking of the supplied
> definition against the existing object. Even the most simplistic
> definition is arguably safer than CREATE OR REPLACE, since that can
> destroy existing data.
How exactly would it do that? You seem to be postulating non-obvious
or not-as-currently-implemented semantics for both variants of the
command, so you had better explain exactly what you think they'd be.
(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.)
regards, tom lane
