Here's a first draft patch for DROP ... IF EXISTS for the remaining
cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION,
AGGREGATE, OPERATOR, CAST and RULE.

comments welcome - working on tests/docs now.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew Dunstan <andrew@dunslane.net> writes:
> Here's a first draft patch for DROP ... IF EXISTS for the remaining
> cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION,
> AGGREGATE, OPERATOR, CAST and RULE.

At what point does this stop being useful and become mere bloat?
The only case I can ever recall being actually asked for was the
TABLE case ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>Here's a first draft patch for DROP ... IF EXISTS for the remaining
>>cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION,
>>AGGREGATE, OPERATOR, CAST and RULE.
>>
>>
>
>At what point does this stop being useful and become mere bloat?
>The only case I can ever recall being actually asked for was the
>TABLE case ...
>
>
>
>

Chris KL said it should be done for all on the grounds of consistency.
But I will happily stop right now if that's not the general view - I'm
only doing this to complete something I started.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >
> >
> >>Here's a first draft patch for DROP ... IF EXISTS for the remaining
> >>cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION,
> >>AGGREGATE, OPERATOR, CAST and RULE.
> >>
> >>
> >
> >At what point does this stop being useful and become mere bloat?
> >The only case I can ever recall being actually asked for was the
> >TABLE case ...
> >
> >
> >
> >
>
> Chris KL said it should be done for all on the grounds of consistency.
> But I will happily stop right now if that's not the general view - I'm
> only doing this to complete something I started.

I am thinking we should have IF EXISTS support for every object that has
CREATE OR REPLACE functionality, plus objects that have storage like
table and perhaps index.

However, I see CREATE ROLE doesn't have REPLACE functionality, so what
is the logic of when we need IF EXISTS and when we don't? Perhaps they
all should have it, and the REPLACE is just for objects you want to
replace but keep existing linkage in place.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Bruce Momjian wrote:

>However, I see CREATE ROLE doesn't have REPLACE functionality, so what
>is the logic of when we need IF EXISTS and when we don't? Perhaps they
>all should have it, and the REPLACE is just for objects you want to
>replace but keep existing linkage in place.
>
>
>

That was my understanding. I think these are orthogonal issues.

Another issue was MySQL compatibility. AFAIK we achieved that when we
did database, following
{ table view index sequence schema type domain conversion}, which pretty
much all had to be done together, as they share the same statement node
type.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

>>> Here's a first draft patch for DROP ... IF EXISTS for the remaining
>>> cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS,
>>> FUNCTION, AGGREGATE, OPERATOR, CAST and RULE.
>>>
>>
>> At what point does this stop being useful and become mere bloat?
>> The only case I can ever recall being actually asked for was the
>> TABLE case ...
>
> Chris KL said it should be done for all on the grounds of consistency.
> But I will happily stop right now if that's not the general view - I'm
> only doing this to complete something I started.

Well, my use-case was to be able to wrap "pg_dump -c" output in
begin/commit tags and being able to run and re-run such dumps without
errors. Basically I don't like 'acceptable errors' when restoring dumps
They just confuse newer users especially.

I also just like consistency

Chris


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Christopher Kings-Lynne wrote:
> >>> Here's a first draft patch for DROP ... IF EXISTS for the remaining
> >>> cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS,
> >>> FUNCTION, AGGREGATE, OPERATOR, CAST and RULE.
> >>>
> >>
> >> At what point does this stop being useful and become mere bloat?
> >> The only case I can ever recall being actually asked for was the
> >> TABLE case ...
> >
> > Chris KL said it should be done for all on the grounds of consistency.
> > But I will happily stop right now if that's not the general view - I'm
> > only doing this to complete something I started.
>
> Well, my use-case was to be able to wrap "pg_dump -c" output in
> begin/commit tags and being able to run and re-run such dumps without
> errors. Basically I don't like 'acceptable errors' when restoring dumps
> They just confuse newer users especially.
>
> I also just like consistency

Makes sense.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian wrote:

>Christopher Kings-Lynne wrote:
>
>
>>>>>Here's a first draft patch for DROP ... IF EXISTS for the remaining
>>>>>cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS,
>>>>>FUNCTION, AGGREGATE, OPERATOR, CAST and RULE.
>>>>>
>>>>>
>>>>>
>>>>At what point does this stop being useful and become mere bloat?
>>>>The only case I can ever recall being actually asked for was the
>>>>TABLE case ...
>>>>
>>>>
>>>Chris KL said it should be done for all on the grounds of consistency.
>>>But I will happily stop right now if that's not the general view - I'm
>>>only doing this to complete something I started.
>>>
>>>
>>Well, my use-case was to be able to wrap "pg_dump -c" output in
>>begin/commit tags and being able to run and re-run such dumps without
>>errors. Basically I don't like 'acceptable errors' when restoring dumps
>> They just confuse newer users especially.
>>
>>I also just like consistency
>>
>>
>
>Makes sense.
>
>
>

What's the consensus on this? Nobody else has chimed in, so I'm inclined
to do no more on the gounds of insufficient demand. Let's decide before
too much bitrot occurs, though.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew Dunstan wrote:
> >>>Chris KL said it should be done for all on the grounds of consistency.
> >>>But I will happily stop right now if that's not the general view - I'm
> >>>only doing this to complete something I started.
> >>>
> >>>
> >>Well, my use-case was to be able to wrap "pg_dump -c" output in
> >>begin/commit tags and being able to run and re-run such dumps without
> >>errors. Basically I don't like 'acceptable errors' when restoring dumps
> >> They just confuse newer users especially.
> >>
> >>I also just like consistency
> >>
> >>
> >
> >Makes sense.
> >
> >
> >
>
> What's the consensus on this? Nobody else has chimed in, so I'm inclined
> to do no more on the gounds of insufficient demand. Let's decide before
> too much bitrot occurs, though.

I kind of liked it, but I think I was the only one.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Fri, Mar 03, 2006 at 03:35:24PM -0500, Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >Christopher Kings-Lynne wrote:
> >
> >
> What's the consensus on this? Nobody else has chimed in, so I'm inclined
> to do no more on the gounds of insufficient demand. Let's decide before
> too much bitrot occurs, though.

+1

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match