Thread: Re: [ADMIN] problems with pg_restore
"Kuhn, Dylan K (4520500D)" <Dylan.Kuhn@navy.mil> writes:
> [ tries to restore a dump into a database with a different name ]
> pg_restore: [archiver (db)] could not execute query: ERROR: Database commen=
> ts may only be applied to the current database
> I'm not sure how to get around this one. Can an archived database with com=
> ments be restored to a database with a different name?
Hm. Evidently not :-(. The COMMENT ON DATABASE facility is a bit bogus
anyway (since there's no way to make the comments visible across
databases). You might be best advised not to use it.
Hackers: this seems like an extremely bad side-effect of what we thought
was a simple addition of a helpful check. I am thinking we should
either remove the check again, or downgrade it to a WARNING (though I'm
not quite sure how to phrase the warning ...). Any thoughts?
regards, tom lane
> Hm. Evidently not :-(. The COMMENT ON DATABASE facility is a bit bogus > anyway (since there's no way to make the comments visible across > databases). You might be best advised not to use it. > > Hackers: this seems like an extremely bad side-effect of what we thought > was a simple addition of a helpful check. I am thinking we should > either remove the check again, or downgrade it to a WARNING (though I'm > not quite sure how to phrase the warning ...). Any thoughts? How about going the other way and removing the requirement to explicitly state the database? COMMENT ON DATABASE IS 'This comment is on the current database.';
Rod Taylor <rbt@rbt.ca> writes:
>> Hackers: this seems like an extremely bad side-effect of what we thought
>> was a simple addition of a helpful check. I am thinking we should
>> either remove the check again, or downgrade it to a WARNING (though I'm
>> not quite sure how to phrase the warning ...). Any thoughts?
> How about going the other way and removing the requirement to explicitly
> state the database?
> COMMENT ON DATABASE IS 'This comment is on the current database.';
Won't help us for reading existing pg_dump scripts, although perhaps it
would be useful going forward.
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 :-(
regards, tom lane
> 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 :-( I like this one for 7.4 (with warning) but remove the requirement to supply a dbname at all with a warning about the deprecated syntax in 7.4. 7.4 pg_dump should not provide dbname. Remove the ability to supply database name completely in 7.5.
Attachment
On Tue, Jul 15, 2003 at 04:03:13PM -0400, Tom Lane wrote: > 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: There's a fourth possibility: ignore the command and issue a WARNING. Restores the database in both cases (in same database and in a different one), and sets the correct comment only if the database name is correct, giving a hint that the comment should be manually set. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "I can't go to a restaurant and order food because I keep looking at the fonts on the menu. Five minutes later I realize that it's also talking about food" (Donald Knuth)
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Tue, Jul 15, 2003 at 04:03:13PM -0400, Tom Lane wrote:
>> 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:
> There's a fourth possibility: ignore the command and issue a WARNING.
Hmm, that seems like a reasonable choice. Anyone have an objection?
regards, tom lane
Tom Lane wrote:
My personal experience would lead me to believe that this is the best option. Count it a vote in favor.
Andrew Biagioni
Alvaro Herrera <alvherre@dcc.uchile.cl> writes:On Tue, Jul 15, 2003 at 04:03:13PM -0400, Tom Lane wrote: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:There's a fourth possibility: ignore the command and issue a WARNING.Hmm, that seems like a reasonable choice. Anyone have an objection?
My personal experience would lead me to believe that this is the best option. Count it a vote in favor.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.orgAndrew Biagioni