Re: OCTET_LENGTH is wrong - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: OCTET_LENGTH is wrong
Date
Msg-id 200111191934.fAJJYv712705@candle.pha.pa.us
Whole thread Raw
In response to Re: OCTET_LENGTH is wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: OCTET_LENGTH is wrong
List pgsql-hackers
Summary:

There have been three ideas of what octet_length() sould return:
1) compressed on-disk storage length2) byte length in server-side encoding3) 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
thereare 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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: OCTET_LENGTH is wrong
Next
From: Bruce Momjian
Date:
Subject: Re: Further open item (Was: Status of 7.2)