Re: [TODO] Process pg_hba.conf keywords as case-insensitive

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-18 02:21:17
Message-ID: 53C8849D.5080200@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/17/2014 01:41 AM, Tom Lane wrote:
> 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.

It's worth noting that pg_ident.conf uses SQL-like case-folding and
quoting, though I don't think it's documented.

We should certainly be using the same thing in pg_hba.conf IMO.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-07-18 03:33:35 Re: [bug fix] pg_ctl always uses the same event source
Previous Message Peter Geoghegan 2014-07-18 02:10:48 Re: Making joins involving ctid work for the benefit of UPSERT