Re: Better to dump tabs as tabs, or \t?

"Marko Kreen" <markokr(at)gmail(dot)com> writes:
> On 5/27/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Historically pg_dump has taken pains to dump ASCII control characters
>> as backslash constructs, for instance \t for tab. I am thinking this
>> is not such a great idea, and that it'd be more portable rather than
>> less so if we got rid of that logic and just dumped tab as tab, etc.
>> In particular, making this play nice with standard_conforming_strings
>> seems unpleasant: we'll have to emit E'' strings which are certainly
>> not portable, not even to older PG releases.

> Could we just give a switch to pg_dump, which toggles between
> standard_confirming_strings and old escaped strings?

The plan is that it'll dump according to what it finds as the
standard_conforming_strings setting on the source server.
If you feel a need to override that setting, you can use PGOPTIONS
or the other usual ways to set a GUC variable for a program.

However, my thought on the point at hand is to just go over to
dumping control characters literally in either case. This is
backwards-compatible to all PG versions and I don't know of a
reason to think it wouldn't work (at least as well as the backslash
constructs anyway) for portability to other databases.

Note: this only affects strings dumped as part of SQL commands;
COPY data isn't at issue, since we're not planning to change the
semantics of that. COPY has always dumped tab as \t and I don't
intend to change it. But pg_dump --inserts would be affected,
also strings appearing in view definitions and such.

We have some precedent for this in that pg_dump has by default
dumped function definitions as $$ literals for a release or two
now, and no one's complained of whitespace getting munged in
function definitions.

regards, tom lane