Brar Piening <b...@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 make 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; 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
