Re: More robust pg_hba.conf parsing/error logging

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More robust pg_hba.conf parsing/error logging
Date: 2009-09-09 18:58:27
Message-ID: 20090909185827.GJ17756@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Andrew Dunstan wrote:
> >> It will affect any dbname or username in mixed or upper case, not just
> >> ALL, won't it?
>
> > No, I am suggesting to change only the comparisons to the literals
> > "all", "sameuser", "samegroup" and "samerole".
>
> Hmm. These words are effectively keywords, so +1 for treating them
> case-insensitively, as we do in SQL. But I wonder whether there isn't
> an argument for making the comparisons of role and database names
> behave more like SQL, too --- that is FOO matches foo but not "FOO".

In general, I think that sounds like a good idea. At the same time, I
wouldn't be against changing the specific 'ALL' special-case comparison
in 8.4.2, using the argument that not many people have moved to it yet
and it's pretty far out there for an 'ALL' database to exist anyway..

Might be too much for a point-release. :/

Just my 2c.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-09-09 19:00:32 Re: [PATCH] plpythonu datatype conversion improvements
Previous Message Alvaro Herrera 2009-09-09 18:50:27 Re: RfD: more powerful "any" types