Re: OCTET_LENGTH is wrong

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

In response to

Browse pgsql-hackers by date

  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)