Thread: 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