Re: OCTET_LENGTH is wrong

Tom,

While the text datatypes have additional issues with encodings, that is 
not true for the bytea type.  I think it does make sense that a client 
be able to get the size in bytes that the bytea type value will return 
to the client.  If you are storing files in a bytea column getting the 
file size by calling octet_length would be very useful.

thanks,
--Barry


Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> 
>>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".
>>
> 
> If I take that argument seriously, I have to conclude that OCTET_LENGTH
> should return the string length measured in the current client encoding
> (which may have little to do with its size in the server, if the
> server's encoding is different).  If the client actually retrieves the
> string then that's how much memory he'll need.
> 
> 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.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 
>