Re: 7.4.1 release status - Turkish Locale
От | Greg Stark |
---|---|
Тема | Re: 7.4.1 release status - Turkish Locale |
Дата | |
Msg-id | 87isigm5b7.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: 7.4.1 release status - Turkish Locale (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 7.4.1 release status - Turkish Locale
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > It seems to me that that's too narrow a definition of the problem. > I think we should state our goal as "we don't want bizarre locale > definitions to interfere with downcasing of the basic ASCII letters". > If we put in a special case for 'I' we will fix the known problem > with Turkish, but what other strange locales might be out there? > And if we don't trust tolower() for 'I', why should we trust it > for 'A'-'Z'? But then wouldn't it be a little weird for Turkish table and column names to treat "I and "Ý" (I think that's a dotted capital I) as equivalent to "i" instead of "ý" "i" respectively. (I think that first one was a dotless i). Perhaps what really ought to be happening is that the downcasing should be done separately for keywords, or postponed until the point where it's checked to see if it's a keyword. Then it could be done using an entirely ascii-centric bit-twiddling implementation. If it matches an SQL keyword after being downcased the old fashioned way, then it's an SQL keyword. If not then the locale-aware tolower() would be appropriate for tables, columns, etc. But then perhaps that's unnecessarily complex. -- greg
В списке pgsql-hackers по дате отправления: