Re: [TODO] Process pg_hba.conf keywords as case-insensitive - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [TODO] Process pg_hba.conf keywords as case-insensitive
Date
Msg-id 30956.1405532518@sss.pgh.pa.us
Whole thread Raw
In response to Re: [TODO] Process pg_hba.conf keywords as case-insensitive  (Christoph Berg <cb@df7cb.de>)
Responses 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  (Craig Ringer <craig@2ndquadrant.com>)
Re: [TODO] Process pg_hba.conf keywords as case-insensitive  (Viswanatham kirankumar <viswanatham.kirankumar@huawei.com>)
List 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 by date:

Previous
From: Christoph Berg
Date:
Subject: Re: [TODO] Process pg_hba.conf keywords as case-insensitive
Next
From: Robert Haas
Date:
Subject: Re: Pg_upgrade and toast tables bug discovered