Обсуждение: Supression of NOTICEs with an ERROR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd like some opinions on fixing the following behavior in 
psql (and postgres in general):

foobar=> CREATE TABLE foo (bar INTEGER);
CREATE
foobar=> CREATE TABLE foo (bar INTEGER UNIQUE);
NOTICE:  CREATE TABLE / UNIQUE will create implicit index 'foo_bar_key' for table 'foo'
ERROR:  Relation 'foo' already exists
turnstep=>

I think that this notice should not appear in this case, since 
the ERROR negates the actual table creation. My first question: 
is this worth pursuing?

My second question is to the method of surpression: I considered 
doing it at the postgres server level, but realized that this 
is probably too radical a change for the numerous clients 
that connect to the server. So, I decided just to do it in 
psql. Is there any NOTICE that should always be displayed, 
even if an ERROR occured (and therefore the query failed)? 
Seems as though the implicit creation of indexes and 
sequences are the major notices used.

Thanks,
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200202060716

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iQA/AwUBPGEf9LybkGcUlkrIEQJpGgCg1y6gUvVO/6aLJfLZTrWtAKNzdggAnRl4
hGCqbSO7/gt5aoPC5TSqMf6E
=alod
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg@turnstep.com> writes:
> I'd like some opinions on fixing the following behavior in 
> psql (and postgres in general):

> foobar=> CREATE TABLE foo (bar INTEGER);
> CREATE
> foobar=> CREATE TABLE foo (bar INTEGER UNIQUE);
> NOTICE:  CREATE TABLE / UNIQUE will create implicit index 'foo_bar_key' for table 'foo'
> ERROR:  Relation 'foo' already exists
> turnstep=>

> I think that this notice should not appear in this case, since 
> the ERROR negates the actual table creation. My first question: 
> is this worth pursuing?

I'd argue that it is not broken.  This isn't really different from the
case ofBEGIN;do something provoking a NOTICE;ROLLBACK;
Would you have the system suppress the NOTICE in this case?

Perhaps more to the point, this particular notice might be useful in
figuring out the reason for the failure --- for example, it might be
that the relation name conflict is not on your table name, but on the
name of an implicitly created index or sequence.  So suppressing the
notice might discard valuable information.

Not everyone likes these notices, and so there has been some talk of
a server configuration variable that could be set to make the server
somewhat less chatty.  This is quite independent of whether the command
ultimately succeeds or fails, however.  In any case I doubt that
hacking psql is a rational way to approach the issue; psql can't be
expected to know all about every sort of notice the backend might issue.
        regards, tom lane