Thread: Making pg_hba.conf case-insensitive
I was looking at this TODO item from 2009:
https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no
I have implemented this in the attached patch. It does two things:
o compares words in columns that can only support keywords as
case-insensitive, double-quoted or not
o compares words in columns that can contain user/db names or keywords
as case-sensitive if double-quoted, case-insensitive if not
Here is the 'local' line we install during initdb, and a newly
identically-behaving line:
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
"LOCAL" ALL ALL TRUST
This 9.6 line:
local Test all trust
would have to be represented in PG 10 as:
local "Test" all trust
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachment
Bruce Momjian <bruce@momjian.us> writes: > I was looking at this TODO item from 2009: > https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no > I have implemented this in the attached patch. It does two things: Is there really enough demand for this to justify subtle breakage of existing pg_hba.conf entries? It'd probably have been fine if we did it like that originally, but I think it's a bit late now. Also, why strcasecmp and not pg_strcasecmp? The former is going to induce misbehavior in e.g. Turkish locales. regards, tom lane
On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > I was looking at this TODO item from 2009: > > https://www.postgresql.org/message-id/4AA7B197.70002%40usit.uio.no > > I have implemented this in the attached patch. It does two things: > > Is there really enough demand for this to justify subtle breakage > of existing pg_hba.conf entries? It'd probably have been fine if > we did it like that originally, but I think it's a bit late now. Well, in 2009 the discussion was whether to backpatch or not, which seems a long way from saying we can't change it in a major release: https://www.postgresql.org/message-id/1336.1252509807%40sss.pgh.pa.us https://www.postgresql.org/message-id/5060.1252523065%40sss.pgh.pa.us It is certainly something we can discuss. > Also, why strcasecmp and not pg_strcasecmp? The former is going > to induce misbehavior in e.g. Turkish locales. OK, changed, and attached. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Attachment
Bruce Momjian <bruce@momjian.us> writes:
> On Thu, Aug 18, 2016 at 02:06:39PM -0400, Tom Lane wrote:
>> Is there really enough demand for this to justify subtle breakage
>> of existing pg_hba.conf entries? It'd probably have been fine if
>> we did it like that originally, but I think it's a bit late now.
> Well, in 2009 the discussion was whether to backpatch or not, which
> seems a long way from saying we can't change it in a major release:
That was seven years ago, which means there's now seven more years
of precedent for the way it works today; and still we've only ever
heard the one complaint. I think documenting the gotcha more clearly
might be the right answer at this point.
regards, tom lane
On 8/18/16 1:59 PM, Bruce Momjian wrote: > o compares words in columns that can only support keywords as > case-insensitive, double-quoted or not > > o compares words in columns that can contain user/db names or keywords > as case-sensitive if double-quoted, case-insensitive if not I can maybe see the case of the second one, but the first one doesn't make sense to me. We've in the past had discussions like this about whether command line arguments of tools should be case insensitive like SQL, and we had resolved that since the shell is not SQL, it shouldn't work like that. pg_hba.conf is also not SQL, and neither, for that matter, is pg_ident.conf and postgresql.conf. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Aug 18, 2016 at 03:01:48PM -0400, Peter Eisentraut wrote: > On 8/18/16 1:59 PM, Bruce Momjian wrote: > > o compares words in columns that can only support keywords as > > case-insensitive, double-quoted or not > > > > o compares words in columns that can contain user/db names or keywords > > as case-sensitive if double-quoted, case-insensitive if not > > I can maybe see the case of the second one, but the first one doesn't > make sense to me. > > We've in the past had discussions like this about whether command line > arguments of tools should be case insensitive like SQL, and we had > resolved that since the shell is not SQL, it shouldn't work like that. > pg_hba.conf is also not SQL, and neither, for that matter, is > pg_ident.conf and postgresql.conf. OK, I am happy to remove the TODO item and see if we get new complaints. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Thu, Aug 18, 2016 at 04:49:04PM -0400, Bruce Momjian wrote: > On Thu, Aug 18, 2016 at 03:01:48PM -0400, Peter Eisentraut wrote: > > On 8/18/16 1:59 PM, Bruce Momjian wrote: > > > o compares words in columns that can only support keywords as > > > case-insensitive, double-quoted or not > > > > > > o compares words in columns that can contain user/db names or keywords > > > as case-sensitive if double-quoted, case-insensitive if not > > > > I can maybe see the case of the second one, but the first one doesn't > > make sense to me. > > > > We've in the past had discussions like this about whether command line > > arguments of tools should be case insensitive like SQL, and we had > > resolved that since the shell is not SQL, it shouldn't work like that. > > pg_hba.conf is also not SQL, and neither, for that matter, is > > pg_ident.conf and postgresql.conf. > > OK, I am happy to remove the TODO item and see if we get new complaints. TODO item removed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +