Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements - Mailing list pgsql-hackers
From | Fabrízio de Royes Mello |
---|---|
Subject | Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements |
Date | |
Msg-id | CAFcNs+ou29yYDrWUF+4LakZakpJCQXW6-pZJdQ4TW4UhehsFTg@mail.gmail.com Whole thread Raw |
In response to | Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
|
List | pgsql-hackers |
<div dir="ltr"><div class="gmail_extra"><br />On Sat, Mar 1, 2014 at 2:11 PM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br />><br />> Fabrízio de Royes Mello <<a href="mailto:fabriziomello@gmail.com">fabriziomello@gmail.com</a>>writes:<br /> > > On Sat, Jan 18, 2014 at 11:12PM, Stephen Frost <<a href="mailto:sfrost@snowman.net">sfrost@snowman.net</a>> wrote:<br />> >> Fabrízio,can you clarify the use-case for things like CREATE AGGREGATE<br /> > >> to have IF NOT EXISTS rather thanOR REPLACE, or if there is a reason<br />> >> why both should exist? Complicating our CREATE options is notsomething<br />> >> we really wish to do without good reason and we certainly don't want to<br /> > >>add something now that we'll wish to remove in another version or two.<br />><br />> > Well I have a scenariowith many servers to deploy DDL scripts, and most of<br />> > them we must run without transaction controlbecause some tasks like CREATE<br /> > > INDEX CONCURRENTLY, DROP/CREATE DATABASE, CLUSTER, etc.<br />><br/>> > When an error occurs the script stops, but the previous commands was<br />> > commited, then wemust review the script to comment parts that was already<br /> > > executed and then run it again. Until now is nota really trouble, but in<br />> > some cases we must deploy another DDL script that contains a new version of<br/>> > some object before we finish to fix the previous version that was in<br /> > > production, and ifwe have CINE for all CREATE objects this task will more<br />> > easy because we just run it again without care ifwill replace the content<br />> > and do not produce an error.<br />><br /> > Why wouldn't COR semantics answerthat requirement just as well, if not<br />> better?<br />><br /><br /></div><div class="gmail_extra">Just becauseit will replace the object content... and in some cases this cannot happen because it will regress the schema to anold version.<br /><br />I know it's a very specific use case, but in a scenario with many servers and many automated tasksin different pipelines, CINE will be very useful. I have this kind of troubles mostly with functions (we use COR), andsometimes we will discover that the production version of function is wrong after we receive a user notify, and in thissituation many times we spend a lot of effort do fix the whole damage.<br /></div><div class="gmail_extra"><br /></div><divclass="gmail_extra">Grettings,<br /><br /></div><div class="gmail_extra">--<br />Fabrízio de Royes Mello<br />Consultoria/CoachingPostgreSQ<br />>> Timbira: <a href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/> >> Blog sobre TI: <a href="http://fabriziomello.blogspot.com">http://fabriziomello.blogspot.com</a><br/>>> Perfil Linkedin: <a href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/> >> Twitter: <a href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a></div></div>
pgsql-hackers by date: