Re: effective_cache_size vs units

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: effective_cache_size vs units
Дата
Msg-id 19636.1167679390@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: effective_cache_size vs units  (Benny Amorsen <benny+usenet@amorsen.dk>)
Список pgsql-hackers
Benny Amorsen <benny+usenet@amorsen.dk> writes:
> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> TL> Personally I don't find the argument about "someday we might want
> TL> to support measurements in millibits" to be convincing at all, and
> TL> certainly it seems weaker than the argument that "units should be
> TL> case insensitive because everything else in this file is". The SQL
> TL> spec has to be considered a more relevant controlling precedent
> TL> for us than the SI units spec, and there are no case-sensitive
> TL> keywords in SQL.

> Units simply are not case sensitive. They are just a more or less
> random collection of preexisting symbols, because that was easier than
> drawing up entirely new ones. Not all are English letters, for one µ
> is not.

You mean "are case sensitive" right?  This is not news.  The point I'm
basically making is that it's not going to hurt us to restrict GUC to
supporting a subset of all-possible-units that can be treated
case-insensitively.  We're already going to restrict the allowed
character set: I can guarantee you that µ, or anything else
outside 7-bit ASCII, will never be accepted.  It's just not worth the
trouble of dealing with multiple possible encodings.
        regards, tom lane


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

Предыдущее
От: Benny Amorsen
Дата:
Сообщение: Re: effective_cache_size vs units
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Status of Fix Domain Casting TODO