Re: [TODO] Process pg_hba.conf keywords as case-insensitive
От | Tom Lane |
---|---|
Тема | Re: [TODO] Process pg_hba.conf keywords as case-insensitive |
Дата | |
Msg-id | 30956.1405532518@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [TODO] Process pg_hba.conf keywords as case-insensitive (Christoph Berg <cb@df7cb.de>) |
Ответы |
Re: [TODO] Process pg_hba.conf keywords as case-insensitive
Re: [TODO] Process pg_hba.conf keywords as case-insensitive Re: [TODO] Process pg_hba.conf keywords as case-insensitive |
Список | pgsql-hackers |
Christoph Berg <cb@df7cb.de> writes: > Re: Viswanatham kirankumar 2014-07-16 <EC867DEF52699D4189B584A14BAA7C2165440538@blreml504-mbx.china.huawei.com> >> Attached patch is implementing following TODO item >> Process pg_hba.conf keywords as case-insensitive > Hmm. I see a case for accepting "ALL" (as in hosts.allow(5)), so +1 on > that, but I don't think the other keywords like "host" and "peer" > should be valid in upper case. I think the argument was that SQL users are accustomed to thinking that keywords are case-insensitive. It makes sense to me that we should adopt that same convention in pg_hba.conf. Re-reading the original thread, there was also concern about whether we should try to make quoting/casefolding behave more like it does in SQL, specifically for matching pg_hba.conf items to SQL identifiers (database and role names). This patch doesn't seem to have addressed that part of it, but I think we need to think those things through before we just do a blind s/strcmp/pg_strcasecmp/g. Otherwise we might find that we've added ambiguity that will give us trouble when we do try to fix that. regards, tom lane
В списке pgsql-hackers по дате отправления: