Re: OCTET_LENGTH is wrong

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: OCTET_LENGTH is wrong
Дата
Msg-id 4189.1006113369@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: OCTET_LENGTH is wrong  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Ответы Re: OCTET_LENGTH is wrong  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: OCTET_LENGTH is wrong  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> On Sun, 18 Nov 2001, Tom Lane wrote:
>> I presume that where you want to come out is OCTET_LENGTH = uncompressed
>> length in the server's encoding ... but so far no one has really made
>> a convincing argument why that answer is better or more spec-compliant
>> than any other answer.  In particular, it's not obvious to me why
>> "number of bytes we're actually using on disk" is wrong.

> I'm not sure, but if we say that the on disk representation is the
> value of the character value expression whose size is being checked,
> wouldn't that be inconsistent with the other uses of the character value

Yeah, it would be and is.  In fact, the present code has some
interesting behaviors: if foo.x is a text value long enough to be
toasted, then you get different results from
SELECT OCTET_LENGTH(x) FROM foo;
SELECT OCTET_LENGTH(x || '') FROM foo;

since the result of the concatenation expression won't be compressed.

I'm not actually here to defend the existing code; in fact I believe the
XXX comment on textoctetlen questioning its correctness is mine.  What
I am trying to point out is that the spec is so vague that it's not
clear what the correct answer is.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: OCTET_LENGTH is wrong
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: 7.2b2 "make check" failure on Red Hat Linux 7.2