"Marko Kreen" <[EMAIL PROTECTED]> writes: > On 5/27/06, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match