From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | lockhart(at)fourpalms(dot)org |
Cc: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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 19:52:16 |
Message-ID: | 3BFAB470.3020906@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart wrote:
>>>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.
>
What practical use does #3 give ;) do you really envision a program that
does 2
separate queries to retrieve some string, first to query its storage
length and then
to actually read it, instead of just reading it ?
I don't think we evan have a interface in any of our libs where we can
give a
pre-allocated buffer to a client library to fill in. Or do we ?
>And everything is a client!
>
So in a PL/PgSQL function doing some data manipulation through SPI the
"client" is
who - the server or the client or some third party ?
---------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-11-20 19:54:30 | Re: Btree doesn't work with ">" condition |
Previous Message | mlw | 2001-11-20 18:16:01 | Re: postgresql.conf (Proposed settings) |