Re: [HACKERS] backslash in psql output

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: dz(at)cs(dot)unitn(dot)it, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] backslash in psql output
Date: 1998-10-18 18:29:13
Message-ID: 199810181829.OAA02208@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-10-18 19:22:42 Re: [HACKERS] SELECT ... LIMIT (trial implementation)
Previous Message Paul A Vixie 1998-10-18 18:22:32 Re: [HACKERS] Re: inet/cidr/bind