Re: pg_dump and backslash escapes

I have seen no reply to my suggestion below, so I assume it is the way
people want to go for 7.3, 7.4, and 8.0.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> 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. +
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
> 

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