On Wed, Jun 20, 2012 at 11:25 AM, Peter Eisentraut <pete...@gmx.net> wrote:
> I don't like these messages any more than the next guy, but why drop
> only those, and not any of the other NOTICE-level messages?  The meaning
> of NOTICE is pretty much, if this is the first time you're using
> PostgreSQL, let me tell you a little bit about how we're doing things
> here.  If you've run your SQL script more than 3 times, you won't need
> them anymore.  So set your client_min_messages to WARNING then.  That
> should be pretty much standard for running SQL scripts, in addition to
> all the other stuff listed here:
> http://petereisentraut.blogspot.fi/2010/03/running-sql-scripts-with-psql.html

Well, let's look at some of the other places where we use NOTICE:

                     errmsg("there is no transaction in progress")));

                        (errmsg("pg_stop_backup cleanup done, waiting
for required WAL segments to be archived")));

        /* translator: %d always has a value larger than 1 */
                (errmsg_plural("drop cascades to %d other object",
                               "drop cascades to %d other objects",
                               numReportedClient + numNotReportedClient,
                               numReportedClient + numNotReportedClient),
                 errdetail("%s", clientdetail.data),
                 errdetail_log("%s", logdetail.data)));

               (errmsg("merging constraint \"%s\" with inherited definition",

                    (errmsg("database \"%s\" does not exist, skipping",

           (errmsg("version \"%s\" of extension \"%s\" is already installed",
                   versionName, stmt->extname)));

                             errmsg("argument type %s is only a shell",

It seems to me that at least some of those have quite a bit more value
than the messages under discussion, and they're not all just tips for
novices.  Maybe you'd want to suppress those when running a script and
maybe you wouldn't, but I think that most people don't want to see the
messages under discussion even in interactive mode, unless perhaps
they are debugging some unexpected behavior.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to