Re: tsearch filenames unlikes special symbols and numbers
От | Pavel Stehule |
---|---|
Тема | Re: tsearch filenames unlikes special symbols and numbers |
Дата | |
Msg-id | 162867790709040818w6ca6d30fi3f9b18db45b86dac@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: tsearch filenames unlikes special symbols and numbers (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2007/9/4, Tom Lane <tgl@sss.pgh.pa.us>: > "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. > ok. I can understand it. But I don't see sense of quoting of params Regards Pavel Stehule
В списке pgsql-hackers по дате отправления: