Re: pg_dump and backslash escapes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump and backslash escapes
Date: 2006-05-13 20:03:03
Message-ID: 5708.1147550583@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
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).

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
unnecessarily hard to use the output to load into other databases
or older PG versions. What I'd like to do is SET
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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2006-05-13 20:46:24 Re: Inheritance, Primary Keys and Foreign Keys
Previous Message Bruce Momjian 2006-05-13 19:38:08 pg_dump and backslash escapes