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 probably
makethe 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; 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?
regards, tom lane