drop if exists remainder

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

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

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

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

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

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

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

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. +

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!

On Saturday 04 March 2006 22:24, David Fetter wrote:

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 :)

+1

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Tom,

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 :)

+1

We were talking about this on IRC, and I feel that if we're going to do "IF
EXISTS" for any objects, we should do it for all objects. Otherwise we
risk a considerable amount of user confusion.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus wrote:

Tom,

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 :)

+1

We were talking about this on IRC, and I feel that if we're going to do "IF
EXISTS" for any objects, we should do it for all objects. Otherwise we
risk a considerable amount of user confusion.

OK there does seem to be some demand for this, so I will rework the
patch, and hope to get it done by feature freeze - it has bitrotted with
7 merge conflicts, including the grammar file, so I need to look
carefully at that. Pity people didn't speak up when this was first
raised. :-)

cheers

andrew

On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote:

OK there does seem to be some demand for this, so I will rework the
patch, and hope to get it done by feature freeze - it has bitrotted
with 7 merge conflicts, including the grammar file, so I need to
look carefully at that. Pity people didn't speak up when this was
first raised. :-)

I did :)

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

David Fetter wrote:

On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote:

OK there does seem to be some demand for this, so I will rework the
patch, and hope to get it done by feature freeze - it has bitrotted
with 7 merge conflicts, including the grammar file, so I need to
look carefully at that. Pity people didn't speak up when this was
first raised. :-)

I did :)

Important as you are, "one swallow does not make a summer".

cheers

andrew

On Thu, Jun 08, 2006 at 12:34:54PM -0400, Andrew Dunstan wrote:

David Fetter wrote:

On Thu, Jun 08, 2006 at 09:43:19AM -0400, Andrew Dunstan wrote:

OK there does seem to be some demand for this, so I will rework the
patch, and hope to get it done by feature freeze - it has bitrotted
with 7 merge conflicts, including the grammar file, so I need to
look carefully at that. Pity people didn't speak up when this was
first raised. :-)

I did :)

Important as you are, "one swallow does not make a summer".

On the other hand, unless we want the lists filling up with a bunch of
+1 posts, it's probably better to assume that unless someone objects a
patch would be accepted.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

Jim C. Nasby wrote:

Important as you are, "one swallow does not make a summer".

On the other hand, unless we want the lists filling up with a bunch of
+1 posts, it's probably better to assume that unless someone objects a
patch would be accepted.

What happened was that Tom objected to (or at least queried the need
for) the patch on the grounds that it was bloat that nobody had asked
for. And when I asked I wasn't exactly deluged with requests to commit,
so I concluded that it was not generally wanted. Since then I have had
probably 10 requests for it, so I am now going to work to update it and
will post a revised patch.

cheers

andrew

Andrew,

What happened was that Tom objected to (or at least queried the need
for) the patch on the grounds that it was bloat that nobody had asked
for. And when I asked I wasn't exactly deluged with requests to commit,
so I concluded that it was not generally wanted.

Did you poll on -hackers or on -patches? A *lot* less people read
-patches.

This has been a problem in the past. I'd generally ask that, if a patch
which was discussed on -hackers gets rejected on -patches, that discussion
be brought back to -hackers. Often the people who supported the original
feature are not on -patches and then are unpleasantly surprised when the
feature they though was accepted doesn't show up in the next version.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus wrote:

Andrew,

What happened was that Tom objected to (or at least queried the need
for) the patch on the grounds that it was bloat that nobody had asked
for. And when I asked I wasn't exactly deluged with requests to commit,
so I concluded that it was not generally wanted.

Did you poll on -hackers or on -patches? A *lot* less people read
-patches.

Yeah. true. Although, I must say that I discovered very early on in my
pg-hacking experience that unless you read -patches too you don't really
know what's going on ;-)

This has been a problem in the past. I'd generally ask that, if a patch
which was discussed on -hackers gets rejected on -patches, that discussion
be brought back to -hackers. Often the people who supported the original
feature are not on -patches and then are unpleasantly surprised when the
feature they though was accepted doesn't show up in the next version.

Fair point. Maybe I only posted on -patches.

cheers

andrew

Andrew Dunstan wrote:

Josh Berkus wrote:

Andrew,

What happened was that Tom objected to (or at least queried the need
for) the patch on the grounds that it was bloat that nobody had asked
for. And when I asked I wasn't exactly deluged with requests to commit,
so I concluded that it was not generally wanted.

Did you poll on -hackers or on -patches? A *lot* less people read
-patches.

Yeah. true. Although, I must say that I discovered very early on in my
pg-hacking experience that unless you read -patches too you don't really
know what's going on ;-)

Actually reading -committers is also a must, because you then know that
something is really going on and it's not just chatter.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support