Re: OCTET_LENGTH is wrong
От | Peter Eisentraut |
---|---|
Тема | Re: OCTET_LENGTH is wrong |
Дата | |
Msg-id | Pine.LNX.4.30.0111181747190.613-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: OCTET_LENGTH is wrong (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: OCTET_LENGTH is wrong
Re: OCTET_LENGTH is wrong |
Список | pgsql-hackers |
Tom Lane writes: > a) Let S be the <string value expression>. If the value of S is > not the null value, then the result is the number of bits in > the value of S. > b) Otherwise, the result is the null value. > > While SQL92 is pretty clear about <bit string>, I'm damned if I can see > anywhere that they define how many bits are in a character string value. > So who's to say what representation is to be used to count the bits? > If, say, UTF-16 and UTF-8 are equally reasonable choices, then why > shouldn't a compressed representation be reasonable too? I think "the value of S" implies "the user-accessible representation of the value of S", in the sense, "How much memory do I need to allocate to store this value". Furthermore, the size of the TOAST representation that is returned now is just one particular of several intermediate representations. For instance, it does not include the VARHDRSZ and it does not include the size of the tuple headers when it's stored externally. Thus, this size is heavily skewed toward low numbers and doesn't tell you much about either the disk end or the user's end. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: