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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)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. +