On Sat, Mar 1, 2014 at 7:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Fabrízio de Royes Mello <fabriziomello@gmail.com> writes: > > On Sat, Mar 1, 2014 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> [ re schema upgrade scenarios ] > >> Why wouldn't COR semantics answer that requirement just as well, if not > >> better? > > > Just because it will replace the object content... and in some cases this > > cannot happen because it will regress the schema to an old version. > > That argument seems awfully darn flimsy.
Sorry, I know my use case is very specific...
We don't have this feature is a strong argument just because we can implement COR instead? Or maybe just we don't want to add more complexity to source code?
The complexity to source code added by this feature is minimal, but the result is very useful, and can be used for many tools (i.e. rails migrations, python alembic, doctrine, and others)
> In any case, given the existence of DO it's simple to code up > create-if-not-exists behavior with a couple lines of plpgsql; that seems > to me to be a sufficient answer for corner cases. create-or-replace is > not equivalently fakable if the system doesn't supply the functionality. >
You are completely right.
But we already have "DROP ... IF EXISTS", then I think if we would have "CREATE ... IF NOT EXISTS" (the inverse behavior) will be very natural... and I agree in implement "CREATE OR REPLACE" too.