Обсуждение: 8.3beta4: pg_dump tab escape change

Hi,

for a very long time now, pg_dump has placed '\t' on output where a literal
tab was present in the data.

Since 8.3pre, this is no longer the case -- the backslash is followed
by an actual tab character, ('\009').

I'm not sure if this change was intentional, but I didn't see it mentioned
in the HISTORY file in 8.3pre4 and to me it feels like a bug, as it makes
writing regexp parsers for database dumps a lot more difficult (and one
needs lookahead assertion support in their regexp engine).

Is there any chance of seeing pg_dump reverted to the original behavior
in this respect?

Thanks,
--
Tomas Szepe <szepe@pinerecords.com>

Tomas Szepe <szepe@pinerecords.com> writes:
> for a very long time now, pg_dump has placed '\t' on output where a literal
> tab was present in the data.
> Since 8.3pre, this is no longer the case -- the backslash is followed
> by an actual tab character, ('\009').

According to the CVS logs, this was reverted in beta4 --- you sure you
are testing the right beta?

            regards, tom lane

> > for a very long time now, pg_dump has placed '\t' on output where a literal
> > tab was present in the data.
> > Since 8.3pre, this is no longer the case -- the backslash is followed
> > by an actual tab character, ('\009').
>
> According to the CVS logs, this was reverted in beta4 --- you sure you
> are testing the right beta?

Yes, I'm 100% positive I'm running 8.3beta4.

Thanks,
--
Tomas Szepe <szepe@pinerecords.com>

Tomas Szepe <szepe@pinerecords.com> writes:
>> According to the CVS logs, this was reverted in beta4 --- you sure you
>> are testing the right beta?

> Yes, I'm 100% positive I'm running 8.3beta4.

[ pokes at it ... ]  Drat, I missed the corner case where the field
delimiter is a control character --- I had tested \r and \n but not \t,
I think.  Will fix.

            regards, tom lane