Re: tsearch filenames unlikes special symbols and numbers
От | Tom Lane |
---|---|
Тема | Re: tsearch filenames unlikes special symbols and numbers |
Дата | |
Msg-id | 23999.1188913981@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: tsearch filenames unlikes special symbols and numbers ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: tsearch filenames unlikes special symbols and numbers
Re: tsearch filenames unlikes special symbols and numbers |
Список | pgsql-hackers |
"Pavel Stehule" <pavel.stehule@gmail.com> writes: > 2007/9/4, Tom Lane <tgl@sss.pgh.pa.us>: >> Yeah, good point. So far it seems that a-z 0-9 and underscore cover the >> real use-cases, so what say we just allow those for now? It's a lot >> easier to loosen up later than tighten up ... > It's system specific. I prefere a-z and A-Z. Clasic name for > dictionaries combine lower and upper characters .. for czech > cs_CZ_UTF8 etc. You're going to need to alter that habit anyway, because it's not appropriate to mention any specific encoding in the dictionary name. But on further thought it strikes me that insisting on all lower case doesn't eliminate case-sensitivity portability problems. For instance, suppose the given parameter is 'foo' and the actual file name is Foo.dict. This will work fine on Windows and will stop working when moved to Unix. So I'm not sure we really buy much by rejecting upper-case letters in the parameter --- all we do is constrain which side of the fence you have to fix any mismatches on. And we picked the side that only a DBA, rather than a plain SQL user, can fix. regards, tom lane
В списке pgsql-hackers по дате отправления: