On 2020/10/15 23:03, Tom Lane wrote:
> Brar Piening <Brar@gmx.de> writes:
>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> I did some more research on this. It turns out timeline 'content' is
>>> the only BYTEA listed in the protocol docs, even though it just passes C
>>> strings to pq_sendbytes(), just like many other fields like the field
>>> above it, the timeline history filename. The proper fix is to change
>>> the code to return the timeline history file contents as TEXT instead of
>>> BYTEA.
>
>> If the timeline history file can contain strings which "may not be made just of ASCII characters" this would
probablymake the client side assume that the content is being sent as TEXT encoded in client_encoding which again isn't
true.
>
> I think this is overthinking the problem, TBH. Yeah, perhaps somebody
> put non-ASCII comments into that file, but they'd probably be expecting
> the exact same encoding they used there to come out the other end.
>
> We should certainly *not* apply byteaout, as that would break cases that
> work fine today;
+1
> and if we do not do that, it is quite misleading to
> suggest that the data is given in bytea format.
>
> I don't really see why our only documentation choices are "text" or
> "bytea". Can't we just write "(raw file contents)" or the like?
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION