Re: OCTET_LENGTH is wrong

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OCTET_LENGTH is wrong
Date: 2001-11-19 19:34:56
Message-ID: 200111191934.fAJJYv712705@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

7.3 will do #2 for all data types. We didn't have text type doing #2 in
7.1.X, but it appears that is the only release where octet_length(text)
returned #1. This is the patch that made octet_length(text) return #1
in 7.1.X:

Revision 1.62 / (download) - annotate - [select for diffs] , Wed Jul 5
23:11:35 2000 UTC (16 months, 2 weeks ago) by tgl
Changes since 1.61: +12 -20 lines
Diff to previous 1.61

Update textin() and textout() to new fmgr style. This is just phase
one of updating the whole text datatype, but there are so dang many
calls of these two routines that it seems worth a separate commit.

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
proper value, as Tom has argued. Tatsuo is happy with #2.

--
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-11-19 20:01:59 New TODO item
Previous Message Bruce Momjian 2001-11-19 19:15:11 Re: OCTET_LENGTH is wrong