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

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >     -- Set escape environment for possible loading into version >= 8.2.
> >     -- If variables are not supported, suppress error messages.
> >     SET client_min_messages = panic;
> >     SET log_min_messages = log;
> >     SET log_min_error_statement = panic;
> >     SET escape_string_warning = off;
> >     SET standard_conforming_strings = off;
> >     RESET log_min_error_statement;
> >     RESET log_min_messages;
> >     RESET client_min_messages;
> 
> Thrashing about with the message level settings like that is useless.
> Either the command will work or it won't.  And we've not bothered to
> try to suppress warnings for any of the other SET commands pg_dump
> issues.  AFAICS all you've accomplished here is to make the dump

Well, the issue with back branches is there is no way to know if the
dump is going to be loaded into the same back-branch, or a newer one,
so I figured we would have to suppress any SET because in the existing
branch, it would fail.

We have discussed the idea of coding the PostgreSQL version number in
the dump somehow so the backend could adjust its behavior based on that
version.  For example, you do SET pg_dump_version = 7.3 and sql standard
strings and backslash warnings are turned off.  That could be
backpatched, I guess.

> dependent on even more GUC variables than it needs to be (consider
> what will happen if we remove/redefine the log level variables in
> future).

True.

> I don't particularly like the way that pg_dump is behaving at the
> moment, ie cluttering the output with E'' strings.  That makes it

Well, it should only do that if there is a backslash in the string.  I
tested a CHECK string and that is how it behaved.

> unnecessarily hard to use the output to load into other databases
> or older PG versions.  What I'd like to do is SET

True.

> standard_conforming_strings appropriately (this probably has to be
> a command line option, since it'll depend on where you want to use
> the output) and then not use E'' strings at all.

Yes, we could do that, but are you saying it is a pg_dump flag, and then
you have to make sure you load into something that has the same
behavior?  That seems quite error-prone.  Having the SET in the dump
seems easier, and it would eliminate the need for E'' in the pg_dump
file.

What if we do something like SET NO VALIDATOR var='val' and if the SET is
not understood, no error is generated?

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