From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | 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 09:12:25 |
Message-ID: | 20011120101224.C15164@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 19, 2001 at 02:34:56PM -0500, Bruce Momjian wrote:
> Summary:
>
> 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
Very nice is possibility of choice... What add everything:
octet_length_storage()
octet_length_server()
octet_length_client()
and problem of right choice put to user. And the standard
octet_length() make as alias to 1) or 2) or 3) -- depend
on result of this discussion.
> The open question is whether we should be doing #3. If you want to use
> octet_length to allocate space on the client side, #3 is really the
If Tom needs be sure, he can uses octet_length_client().
> proper value, as Tom has argued. Tatsuo is happy with #2.
...and Tatsuo can uses octet_length_server(). The important thing
is that both will still happy :-)
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-11-20 09:53:47 | Re: OCTET_LENGTH is wrong |
Previous Message | Karel Zak | 2001-11-20 08:45:31 | Re: import/export of large objects on server-side |