Re: [HACKERS] backslash in psql output

(Sorry for being so slow to respond to this...)

Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it> writes:
> I believe that the right way to handle all this stuff is the following:

> input:

> binary data escaped data
> | |
> (user conversion) (psql input)
> | |
> +-----------------------+
> |
> escaped query
> |
> (libpq)
> |
> escaped query escaped data
> | |
> (parser unescape) (copy-from unescape)
> | |
> +-----------------------+
> |
> binary data
> |
> (input function)
> |
> internal data

> output:

> internal data
> |
> (output function)
> |
> escaped data
> |
> +-----------------------+
> | |
> (libpq) (copy-to)
> | |
> escaped data escaped data
> |
> |
> +-----------------------+-----------------------+
> | | |
> (user conversion) (psql output) (psql unescape)
> | | |
> binary data escaped data binary data

I disagree with this, at least for the output side. The FE/BE protocol
for SELECT/FETCH results is already completely 8-bit clean. There is
no reason to escape output data before passing it across the wire and
through libpq. The application program might want to escape the data
for its own purposes, but that's not our concern.

As far as I can tell, COPY IN/OUT data is the only case where we really
have an issue. Since the COPY protocol is inherently text-based, we
have to escape anything that won't do as text. (Offhand, I think only
tab, newline, null, and of course backslash are essential to convert,
though we might also want to convert other nonprinting characters for
readability's sake.) The conversions involved need to be nailed down
and documented as part of the FE/BE protocol.

Coping with array-valued fields is also a concern --- there needs to
be some reasonable way for an application to discover that a given field
is an array and what datatype it is an array of. But I think the need
there is to extend the RowDescription information returned by SELECT,
not to modify the data representation.

regards, tom lane