From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christoph Berg <cb(at)df7cb(dot)de> |
Cc: | Viswanatham kirankumar <viswanatham(dot)kirankumar(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [TODO] Process pg_hba.conf keywords as case-insensitive |
Date: | 2014-07-16 17:41:58 |
Message-ID: | 30956.1405532518@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christoph Berg <cb(at)df7cb(dot)de> writes:
> Re: Viswanatham kirankumar 2014-07-16 <EC867DEF52699D4189B584A14BAA7C2165440538(at)blreml504-mbx(dot)china(dot)huawei(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-07-16 18:00:48 | Re: Pg_upgrade and toast tables bug discovered |
Previous Message | Christoph Berg | 2014-07-16 17:10:58 | Re: [TODO] Process pg_hba.conf keywords as case-insensitive |