Re: [HACKERS] Logical Replication and Character encoding - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Logical Replication and Character encoding
Date
Msg-id 88397afa-a8ec-8d8a-1c94-94a4795a3870@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Logical Replication and Character encoding  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] Logical Replication and Character encoding  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On 3/3/17 14:51, Petr Jelinek wrote:
> On 03/03/17 20:37, Peter Eisentraut wrote:
>> On 2/27/17 00:23, Kyotaro HORIGUCHI wrote:
>>> Yeah, the patch sends converted string with the length of the
>>> orignal length. Usually encoding conversion changes the length of
>>> a string. I doubt that the reverse case was working correctly.
>>
>> I think we shouldn't send the length value at all.  This might have been
>> a leftover from an earlier version of the patch.
>>
>> See attached patch that removes the length value.
>>
> 
> Well the length is necessary to be able to add binary format support in
> future so it's definitely not an omission.

Right.  So it appears the right function to use here is
pq_sendcountedtext().  However, this sends the strings without null
termination, so we'd have to do extra processing on the receiving end.
Or we could add an option to pq_sendcountedtext() to make it do what we
want.  I'd rather stick to standard pqformat.c functions for handling
the protocol.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] PATCH: two slab-like memory allocators
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API inlibpqwalreceiver