
> Given the current implementation, it seems like there are 
> three possible
> behaviors for COMMENT ON DATABASE when the database name 
> isn't the same
> as the current database:
> 
> 1. Raise error (what we're doing now).  Simple but breaks dump scripts
>    for the restore-into-different-DB scenario.
> 
> 2. Do nothing, store the comment in the current DB's pg_description
>    (what we did in 7.2).  Now that I think about it, this also fails
>    for different-database restore, since very possibly the attempt
>    to look up the DB name will fail --- you'll get a no-such-database
>    error instead of the present error, but it's still unhelpful.
> 
> 3. Ignore the specified DB name, store the comment as the description
>    of the current DB; possibly give a warning saying we're doing so.
>    This would allow correct restoration of dumps into different DBs,
>    but I think people would find it awfully surprising :-(
> 

The behavior and syntax of COMMENT ON DATABASE was surprising to me from the start.  IMHO, a warning that doesn't affect my current transaction is a more pleasant surprise than an error that aborts it.  It would be nice if there was an easier way to undo a mistake, but again I would rather finish my transaction with an incorrect comment than have to do it over again, so I'd take door #3.

Could there be a #4, drop support for COMMENT ON DATABASE, ignoring it and issuing a warning that it is no longer supported?  It's hard to argue that it's very useful as it stands, and you've already recommended against using it.

-dylan-  

Tue, 15 Jul 2003 13:26:37 -0700
"Kuhn, Dylan K (4520500D)" <Dylan.Kuhn@navy.mil>
Re: problems with pg_restore 