> 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-
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
