> 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.
\. as end-of-input is also escaped. Not sure that gets sent to the
backend, or is just used by the frontend protocol to signal
end-of-input.
>
> 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.
Yes, arrays can be a problem. Not sure.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026