Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching"
От | Tom Lane |
---|---|
Тема | Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching" |
Дата | |
Msg-id | 8831.1304786489@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching" (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Backpatching of "Teach the regular expression functions
to do case-insensitive matching"
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On the flip side, the risk of it flat-out blowing up seems pretty > small. For someone to invent their own version of wchar_t that uses > something other than Unicode code points would be pretty much pure > masochism, wouldn't it? Well, no, that's not clear. The C standard has pretty carefully avoided constraining the wchar_t representation, so implementors are free to do whatever is most convenient from the standpoint of their library routines. I could easily see somebody deciding to do something that wasn't quite Unicode because it let him re-use lookup tables designed for some other encoding, or some such. Now it's also perfectly possible, maybe even likely, that nobody's done that on any platform we care about. But I don't believe we know that with any degree of certainty. We definitely have not made any effort to establish whether it's true --- for example, we have no regression tests that address the point. (I think that collate.linux.utf8 touches on it, but we're a long way from being able to run that on non-glibc platforms...) regards, tom lane
В списке pgsql-hackers по дате отправления: