From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Better to dump tabs as tabs, or \t? |
Date: | 2006-05-27 20:37:35 |
Message-ID: | e51f66da0605271337j23d0624ck63f9685e8166e482@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
IMHO this decision is similar to COPY/INSERT decision - it depends
what the admin plans to with the dump, what tools are user on it,
whether there is need to reload on older postgres, etc - and all
of them are things that the postgres tools cannot deduce.
By default, pg_dump should output standard_conforming_strings,
that being in sync with policy to move to standard SQL quoting.
And when the switch is given, pg_dump should put SET at the
start of the dump, not use E'' stings, so giving option
for being backwards compatible.
Such option would considerably lower the pain of migrating data
between versions.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-27 20:45:27 | Re: anoncvs still slow |
Previous Message | Andrew Dunstan | 2006-05-27 20:14:21 | Re: Better to dump tabs as tabs, or \t? |