Re: OCTET_LENGTH is wrong - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: OCTET_LENGTH is wrong
Date
Msg-id Pine.LNX.4.30.0111181747190.613-100000@peter.localdomain
Whole thread Raw
In response to Re: OCTET_LENGTH is wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: OCTET_LENGTH is wrong
Re: OCTET_LENGTH is wrong
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: TODO item inquiry/claim
Next
From: Peter Eisentraut
Date:
Subject: Re: beta3