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
Re: OCTET_LENGTH is wrong |
Список | 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 по дате отправления: