Обсуждение: BUG #3760: Comment on restore database
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
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