| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Benny Amorsen <benny+usenet(at)amorsen(dot)dk> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: effective_cache_size vs units |
| Date: | 2007-01-01 19:23:10 |
| Message-ID: | 19636.1167679390@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Benny Amorsen <benny+usenet(at)amorsen(dot)dk> writes:
> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2007-01-01 21:54:21 | Status of Fix Domain Casting TODO |
| Previous Message | Benny Amorsen | 2007-01-01 19:10:46 | Re: effective_cache_size vs units |