Re: OCTET_LENGTH is wrong
От | Tom Lane |
---|---|
Тема | Re: OCTET_LENGTH is wrong |
Дата | |
Msg-id | 22060.1006195083@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: OCTET_LENGTH is wrong (Barry Lind <barry@xythos.com>) |
Ответы |
Re: OCTET_LENGTH is wrong
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: