Re: OCTET_LENGTH is wrong

Peter Eisentraut <peter_e@gmx.net> writes:
> ... Moreover, it eliminates the standard useful behaviour of
> OCTET_LENGTH, which is to show the length in bytes of a multibyte string.

While I don't necessarily dispute this, I do kinda wonder where you
derive the statement.  AFAICS, SQL92 defines OCTET_LENGTH in terms
of BIT_LENGTH:

6.6 General Rule 5:
           a) Let S be the <string value expression>. If the value of S is             not the null value, then the
resultis the smallest integer             not less than the quotient of the division (BIT_LENGTH(S)/8).           b)
Otherwise,the result is the null value.
 

and BIT_LENGTH is defined in the next GR:
           a) Let S be the <string value expression>. If the value of S is             not the null value, then the
resultis 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?
        regards, tom lane