Re: pg_dump and backslash escapes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_dump and backslash escapes
Date
Msg-id 200605171506.k4HF6mE12474@candle.pha.pa.us
Whole thread Raw
In response to Re: pg_dump and backslash escapes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump and backslash escapes
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > You mean dumping and reloading pg_dump output in 7.3 generates errors? 
> > I didn't know.  Can you give an example?  I wasn't aware of that.
> 
> Well, looking at the SETs already currently emitted:
> 
> $ pg_dump -s regression | grep ^SET
> SET client_encoding = 'SQL_ASCII';    fails before 7.1
> SET check_function_bodies = false;    fails before 7.4
> SET client_min_messages = warning;    fails before 7.3
> SET search_path = public, pg_catalog;    fails before 7.3
> SET default_tablespace = '';        fails before 8.0
> SET default_with_oids = false;        fails before 8.0
> 
> so I'm not at all clear what you've got against this one.

Very clear.  The issue is that I can't find any of these emitted by a
pg_dump version who's native backend doesn't understand them.

I assume that it is expected that a cross-db dump/reload will generate
errors, and it is done rarely for upgrades, but I assume same-version
dump/restore is done more frequently and people don't expect errors.
Is that not a significant distinction?

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Compression and on-disk sorting
Next
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: Return results for PQexec vs PQexecP*