Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2010-02-23 Thread Bruce Momjian
Robert Haas wrote: > On Tue, Feb 23, 2010 at 12:22 AM, Bruce Momjian wrote: > > Tom Lane wrote: > >> Alvaro Herrera 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

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2010-02-23 Thread Robert Haas
On Tue, Feb 23, 2010 at 12:22 AM, Bruce Momjian wrote: > Tom Lane wrote: >> Alvaro Herrera 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 literal

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2010-02-22 Thread Bruce Momjian
Tom Lane wrote: > Alvaro Herrera 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". What happ

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Tom Lane
Stephen Frost writes: > 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

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera 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

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Tom Lane
Alvaro Herrera 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 keywo

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Rafael Martinez
Alvaro Herrera wrote: > Rafael Martinez wrote: > >> Shouldn't 'all' be a reserved word?, it has a special meaning when used >> in pg_hba.conf. > > No, it works fine with a line like this: > > local "all" all md5 > Ok, then "all" and "ALL" should be valid values but not al

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Alvaro Herrera
Rafael Martinez wrote: > Shouldn't 'all' be a reserved word?, it has a special meaning when used > in pg_hba.conf. No, it works fine with a line like this: local "all" all md5 -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Repl

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Alvaro Herrera
Andrew Dunstan wrote: > Alvaro Herrera wrote: > >Surely if you want to designate a database named ALL you should use > >quotes, same as if you wanted to designate a database named all (see my > >other followup). > > OK, but if we move to using pg_strcasecmp() that would be a > behaviour change,

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Rafael Martinez
Andrew Dunstan wrote: > > > Rafael Martinez wrote: >> >> Or throw an error saying 'ALL' is not a valid value and *not* reload the >> pg_hba.conf file. > > > But it's not invalid. It would designate a database or user named "ALL". > That might be a silly thing to do, but that's another questi

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Andrew Dunstan
Alvaro Herrera wrote: Andrew Dunstan wrote: Rafael Martinez wrote: Or throw an error saying 'ALL' is not a valid value and *not* reload the pg_hba.conf file. But it's not invalid. It would designate a database or user named "ALL". That might be a silly thing to do, but that's

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Alvaro Herrera
Andrew Dunstan wrote: > Rafael Martinez wrote: > > > >Or throw an error saying 'ALL' is not a valid value and *not* reload the > >pg_hba.conf file. > > But it's not invalid. It would designate a database or user named > "ALL". That might be a silly thing to do, but that's another > question. Sur

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Alvaro Herrera
Rafael Martinez wrote: > Problem: > - > If you define in pg_hba.conf a database or a user value with 'ALL' > instead of 'all', you will lose access to *all* databases involved. The > reload process will not report anything about 'ALL' been an invalid > value and the new pg_hba.conf will b

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Andrew Dunstan
Rafael Martinez wrote: Or throw an error saying 'ALL' is not a valid value and *not* reload the pg_hba.conf file. But it's not invalid. It would designate a database or user named "ALL". That might be a silly thing to do, but that's another question. cheers andrew -- Sent via pgsql

[HACKERS] More robust pg_hba.conf parsing/error logging

2009-09-09 Thread Rafael Martinez
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello The origin of this petition is an error produced today by a user on one of our systems. Because of this error many users lost access to their databases. Problem: - If you define in pg_hba.conf a database or a user value with 'ALL' inst