From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: OCTET_LENGTH is wrong |
Date: | 2001-11-18 19:56:09 |
Message-ID: | 4189.1006113369@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-11-18 20:40:12 | Re: 7.2b2 "make check" failure on Red Hat Linux 7.2 |
Previous Message | Stephan Szabo | 2001-11-18 19:40:59 | Re: OCTET_LENGTH is wrong |