Re: OCTET_LENGTH is wrong

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: OCTET_LENGTH is wrong
Дата
Msg-id 20011118113200.I38778-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на Re: OCTET_LENGTH is wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: OCTET_LENGTH is wrong  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, 18 Nov 2001, 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.

I'm not sure, but if we say that the on disk representation is the
value of the character value expression whose size is being checked,
wouldn't that be inconsistent with the other uses of the character value
expression in places like substr where we don't use the on disk
representation?  Unless you're saying that the string value expression
that is that character value expression is the compressed one and
the character value expression is the uncompressed one.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: full outer join bug?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: OCTET_LENGTH is wrong