From: | Daniel Farina <drfarina(at)acm(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE ... IF EXISTS feature? |
Date: | 2010-11-05 16:31:19 |
Message-ID: | AANLkTimfxPtBJd3MtUqdT9oSWeRrgv4f6pomxQFL5GVG@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 5, 2010 at 8:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> That spells "large maintenance burden" to me, even if any one command
> would be relatively simple to fix. And we haven't even reached the
> question of whether pg_dump could use these things usefully; I suspect
> that the bottom-line issue there might be something else entirely.
Well, why not? I was in the middle of writing it. But I'm open to
other approaches, the real motivating issue could be stated simply as:
"pg_dump --clean should produce output that can be run on empty, full
or partially-full databases in a transaction without a non-zero error
code"
ALTER IF EXISTS just struck me as one such mechanism that is familiar
looking, at least.
Also take note that I suffered from some syntactic dyslexia above, IF
EXISTS doesn't appear to ever occur after the identifier, so the
example would be:
ALTER TABLE IF EXISTS foo DROP CONSTRAINT IF EXISTS bar;
To me this reads fine, although I agree that it could be annoying to
main this optional-ness on a large series of commands.
One might be able to imagine a special backend function to do this
missing-identifier guarding, that may shorten the whole thing up a
bit...any suggestions, in that line of thinking or others?
fdr
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-05 16:48:02 | Re: ALTER OBJECT any_name SET SCHEMA name |
Previous Message | Dimitri Fontaine | 2010-11-05 16:16:37 | Re: ALTER OBJECT any_name SET SCHEMA name |