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
>
>