Thread: pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ...

CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    tgl@svr1.postgresql.org    03/10/05 23:38:53

Modified files:
    doc/src/sgml/ref: copy.sgml
    src/backend/commands: copy.c

Log message:
    Modify COPY FROM to match the null-value string against the column value
    before it is de-backslashed, not after.  This allows the null string \N
    to be reliably distinguished from the data value \N (which must be
    represented as \\N).  Per bug report from Manfred Koizar ... but it's
    amazing this hasn't been reported before ...
    Also, be consistent about encoding conversion for null string: the form
    specified in the command is in the server encoding, but what is sent
    to/from client must be in client encoding.  This never worked quite
    right before either.

On Sun, 2003-10-05 at 22:38, Tom Lane wrote:
>     Modify COPY FROM to match the null-value string against the column value
>     before it is de-backslashed, not after.  This allows the null string \N
>     to be reliably distinguished from the data value \N (which must be
>     represented as \\N).  Per bug report from Manfred Koizar ... but it's
>     amazing this hasn't been reported before ...
>     Also, be consistent about encoding conversion for null string: the form
>     specified in the command is in the server encoding, but what is sent
>     to/from client must be in client encoding.  This never worked quite
>     right before either.

Should either of these be backpatched to 7.3?

-Neil

Neil Conway <neilc@samurai.com> writes:
> On Sun, 2003-10-05 at 22:38, Tom Lane wrote:
>> Modify COPY FROM to match the null-value string against the column value
>> before it is de-backslashed, not after.  This allows the null string \N
>> to be reliably distinguished from the data value \N (which must be
>> represented as \\N).  Per bug report from Manfred Koizar ... but it's
>> amazing this hasn't been reported before ...
>> Also, be consistent about encoding conversion for null string: the form
>> specified in the command is in the server encoding, but what is sent
>> to/from client must be in client encoding.  This never worked quite
>> right before either.

> Should either of these be backpatched to 7.3?

It was a minor change given previous hacking on 7.4, but I don't see any
simple way to backpatch to 7.3.  We'd have to backport some nontrivial
changes that (IMHO) aren't well enough proven yet.  So even though there
is clearly a bug here, it's a bug that's escaped detection for N years,
and so I'm not eager to risk introducing other bugs in order to squash
it.

Once the fixed code has undergone some field testing I'd be willing to
backpatch it, but by then the issue may be moot ...

            regards, tom lane

On Mon, 2003-10-06 at 00:02, Tom Lane wrote:
> It was a minor change given previous hacking on 7.4, but I don't see any
> simple way to backpatch to 7.3.  We'd have to backport some nontrivial
> changes that (IMHO) aren't well enough proven yet.

That's fine (and that's what I suspected). I agree it's probably not
worth doing right now.

-Neil