Re: OCTET_LENGTH is wrong

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: OCTET_LENGTH is wrong
Дата
Msg-id 200111191934.fAJJYv712705@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: OCTET_LENGTH is wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: OCTET_LENGTH is wrong
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: OCTET_LENGTH is wrong
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Further open item (Was: Status of 7.2)