Re: pg_dump bug in 9.4beta2 and HEAD - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_dump bug in 9.4beta2 and HEAD
Date
Msg-id 20140814133734.GB7096@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pg_dump bug in 9.4beta2 and HEAD  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
Heikki Linnakangas wrote:

> The quick fix would be to add an exception for blobs, close to where
> Assert is. There are a few exceptions there already. A cleaner
> solution would be to add a new argument to ArchiveEntry and make the
> callers responsible for providing an "DROP IF EXISTS" query, but
> that's not too appetizing because for most callers it would be
> boring boilerplate code. Perhaps add an argument, but if it's NULL,
> ArchiveEntry would form the if-exists query automatically from the
> DROP query.

Yeah, this was discussed (or at least mentioned) in the original thread.
See
http://www.postgresql.org/message-id/20140228183100.GU4759@eldon.alvh.no-ip.org
where I wrote:

: I still find the code to inject IF EXISTS to the DROP commands ugly as
: sin.  I would propose to stop storing the dropStmt in the archive
: anymore; instead just store the object identity, which can later be used
: to generate both DROP commands, with or without IF EXISTS, and the ALTER
: OWNER commands.  However, that's a larger project and I don't think we
: need to burden this patch with that.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Compute attr_needed for child relations (was Re: inherit support for foreign tables)
Next
From: Stephen Frost
Date:
Subject: Re: replication commands and log_statements