On Thu, Oct 15, 2020 at 10:03:46AM -0400, Tom Lane wrote: > 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?
Agreed. The reason they are those labels is that the C code has to label the output fields, so it can only use SQL types. There are many protocol fields mislabeled in this way, not just timeline history. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
