| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | lockhart(at)fourpalms(dot)org |
| Cc: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: OCTET_LENGTH is wrong |
| Date: | 2001-11-20 15:27:31 |
| Message-ID: | 200111201527.fAKFRVh07636@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > There have been three ideas of what octet_length() sould return:
> > > 1) compressed on-disk storage length
> > > 2) byte length in server-side encoding
> > > 3) byte length in client-side encoding
> ...
> > > The open question is whether we should be doing #3.
>
> There is no question in my mind that (3) must be the result of
> octet_length(). Any of the other options may give an interesting result,
> but of no practical use to a client trying to retrieve data. And
> everything is a client!
Added to TODO:
* Add octet_length_server() and octet_length_client() (Thomas, Tatsuo)
--
Bruce Momjian | http://candle.pha.pa.us
pgman(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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-11-20 15:28:32 | Re: OCTET_LENGTH is wrong |
| Previous Message | Tom Lane | 2001-11-20 15:16:57 | Re: beta3 |