Barry Lind <barry@xythos.com> writes:
> 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.
bytea does that already. It's only text that has (or had, till a few
minutes ago) the funny behavior.
I'm not set on the notion that octet_length should return on-disk size;
that's clearly not what's contemplated by SQL92, so I'm happy to agree
that if we want that we should add a new function to get it.
("storage_length", maybe.) What's bothering me right now is the
difference between client and server encodings. It seems that the only
plausible use for octet_length is to do memory allocation on the client
side, and for that purpose the length ought to be measured in the client
encoding. People seem to be happy with letting octet_length take the
easy way out (measure in the server encoding), and I'm trying to get
someone to explain to me why that's the right behavior. I don't see it.
regards, tom lane