BUG #3760: Comment on restore database

Malcus Imhof wrote:

The following bug has been logged online:

Bug reference: 3760
Logged by: Malcus Imhof
Email address: malcus@terra.com.br
PostgreSQL version: 8.2.5
Operating system: Windows 2003
Description: Comment on restore database
Details:

When I'm restoring a dump done in a database called "client" on a new
database called "new_database" shows a error when the pg_restore try to
restore the comment:

C:\Arquivos de programas\pgAdmin III\1.8\pg_restore.exe -i -h 192.168.0.11
-p 5432 -U postgres -d "new_database" -v "C:\Documents and
Settings\Ciro\Desktop\client.backup"
pg_restore: connecting to database for restore
pg_restore: creating COMMENT DATABASE "client"
pg_restore: WARNING: database "client" does not exist

Yea, the dump thinks it is going into the same database. I don't see
any way of fixing that. We don't allow functions for the object name.
If we did we could use current_database(). Fortunately I think it is
the only place where the database name is hardcoded in the dump.

I have added a TODO item:

o Allow COMMENT ON dbname to work when loading into a database
with a different name

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Malcus Imhof wrote:

Yea, the dump thinks it is going into the same database. I don't see
any way of fixing that. We don't allow functions for the object name.
If we did we could use current_database(). Fortunately I think it is
the only place where the database name is hardcoded in the dump.

The easiest would be to add new syntax,
COMMENT ON CURRENT DATABASE IS 'foo'

--
Alvaro Herrera http://www.advogato.org/person/alvherre
"Llegar� una �poca en la que una investigaci�n diligente y prolongada sacar�
a la luz cosas que hoy est�n ocultas" (S�neca, siglo I)

Alvaro Herrera wrote:

Bruce Momjian wrote:

Malcus Imhof wrote:

Yea, the dump thinks it is going into the same database. I don't see
any way of fixing that. We don't allow functions for the object name.
If we did we could use current_database(). Fortunately I think it is
the only place where the database name is hardcoded in the dump.

The easiest would be to add new syntax,
COMMENT ON CURRENT DATABASE IS 'foo'

Yea, probably. I have added that as possible syntax to the TODO list.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, 2007-11-19 at 14:27 -0500, Bruce Momjian wrote:

Alvaro Herrera wrote:

Bruce Momjian wrote:

Malcus Imhof wrote:

Yea, the dump thinks it is going into the same database. I don't see
any way of fixing that. We don't allow functions for the object name.
If we did we could use current_database(). Fortunately I think it is
the only place where the database name is hardcoded in the dump.

The easiest would be to add new syntax,
COMMENT ON CURRENT DATABASE IS 'foo'

Yea, probably. I have added that as possible syntax to the TODO list.

Can we implement something for 8.3 please?

Suggested syntax even simpler

COMMENT ON DATABASE IS 'text';

to set the comment on the current database.

Reason to do this now: Perf Tips have been changed for 8.3 to recommend
using --single-transaction when restoring pg_dumps, because of fast COPY
enhancement. Allowing this to cause an error will prevent the whole dump
from restoring. That will force people to find the cause of the error,
for which there is no hint, edit the file and resubmit.

Fairly simple to allow working syntax, and useful too.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs <simon@2ndquadrant.com> writes:

Reason to do this now: Perf Tips have been changed for 8.3 to recommend
using --single-transaction when restoring pg_dumps, because of fast COPY
enhancement. Allowing this to cause an error will prevent the whole dump
from restoring.

If it were indeed an error condition, this argument might have some
merit. Since it is not, I don't have a lot of sympathy for a hasty
last-minute change.

regression=# comment on database foo is 'z';
WARNING: database "foo" does not exist
COMMENT

regards, tom lane

Bruce Momjian <bruce@momjian.us> writes:

I have added a TODO item:

o Allow COMMENT ON dbname to work when loading into a database
with a different name

This is an extremely poorly phrased TODO item. The problem is not that
you can't comment on a database with a different name --- that's worked
ever since pg_shdescription was added.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I have added a TODO item:

o Allow COMMENT ON dbname to work when loading into a database
with a different name

This is an extremely poorly phrased TODO item. The problem is not that
you can't comment on a database with a different name --- that's worked
ever since pg_shdescription was added.

OK, updated:

o Prevent COMMENT ON dbname from issuing a warning when loading
into a database with a different name, perhaps using COMMENT ON
CURRENT DATABASE

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

This is an extremely poorly phrased TODO item.

OK, updated:

o Prevent COMMENT ON dbname from issuing a warning when loading
into a database with a different name, perhaps using COMMENT ON
CURRENT DATABASE

That's not any better, because the warning isn't the problem either.
Perhaps:

o Change pg_dump so that any comment on the dumped database is
applied to the database the dump is loaded into, even if
its database name is different. This will require new
backend syntax, perhaps COMMENT ON CURRENT DATABASE.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

This is an extremely poorly phrased TODO item.

OK, updated:

o Prevent COMMENT ON dbname from issuing a warning when loading
into a database with a different name, perhaps using COMMENT ON
CURRENT DATABASE

That's not any better, because the warning isn't the problem either.
Perhaps:

o Change pg_dump so that any comment on the dumped database is
applied to the database the dump is loaded into, even if
its database name is different. This will require new
backend syntax, perhaps COMMENT ON CURRENT DATABASE.

Thanks, done:

o Change pg_dump so that a comment on the dumped database is
applied to the loaded database, even if the database has a
different name. This will require new backend syntax, perhaps
COMMENT ON CURRENT DATABASE.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, 2007-11-19 at 18:38 -0500, Tom Lane wrote:

Simon Riggs <simon@2ndquadrant.com> writes:

Reason to do this now: Perf Tips have been changed for 8.3 to recommend
using --single-transaction when restoring pg_dumps, because of fast COPY
enhancement. Allowing this to cause an error will prevent the whole dump
from restoring.

If it were indeed an error condition, this argument might have some
merit. Since it is not, I don't have a lot of sympathy for a hasty
last-minute change.

Well, if its not an ERROR condition, no problem. I interpreted failure
to mean ERROR, which luckily it isn't.

The failure of the COMMENT isn't any reason for a last-minute change, so
request withdrawn.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com