Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
Date: 2014-03-01 22:25:36
Message-ID: CAFcNs+ou29yYDrWUF+4LakZakpJCQXW6-pZJdQ4TW4UhehsFTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 1, 2014 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com>
writes:
> > On Sat, Jan 18, 2014 at 11:12 PM, Stephen Frost <sfrost(at)snowman(dot)net>
wrote:
> >> Fabrízio, can you clarify the use-case for things like CREATE AGGREGATE
> >> to have IF NOT EXISTS rather than OR REPLACE, or if there is a reason
> >> why both should exist? Complicating our CREATE options is not
something
> >> we really wish to do without good reason and we certainly don't want to
> >> add something now that we'll wish to remove in another version or two.
>
> > Well I have a scenario with many servers to deploy DDL scripts, and
most of
> > them we must run without transaction control because some tasks like
CREATE
> > INDEX CONCURRENTLY, DROP/CREATE DATABASE, CLUSTER, etc.
>
> > When an error occurs the script stops, but the previous commands was
> > commited, then we must review the script to comment parts that was
already
> > executed and then run it again. Until now is not a really trouble, but
in
> > some cases we must deploy another DDL script that contains a new
version of
> > some object before we finish to fix the previous version that was in
> > production, and if we have CINE for all CREATE objects this task will
more
> > easy because we just run it again without care if will replace the
content
> > and do not produce an error.
>
> 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.

I know it's a very specific use case, but in a scenario with many servers
and many automated tasks in different pipelines, CINE will be very useful.
I have this kind of troubles mostly with functions (we use COR), and
sometimes we will discover that the production version of function is wrong
after we receive a user notify, and in this situation many times we spend a
lot of effort do fix the whole damage.

Grettings,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQ
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-01 22:39:00 Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
Previous Message Tom Lane 2014-03-01 22:10:21 Re: Securing "make check" (CVE-2014-0067)