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