Re: OCTET_LENGTH is wrong

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

In response to

Responses

Browse pgsql-hackers by date

  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