Re: Aw: Re: Minor documentation error regarding streaming replication protocol

On Thu, Oct 15, 2020 at 10:03:46AM -0400, Tom Lane wrote:
> Brar Piening <Brar(at)gmx(dot)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 <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee