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 по дате отправления: