Re: OCTET_LENGTH is wrong

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(at)gmx(dot)net