2011/6/21 Alvaro Herrera <alvhe...@commandprompt.com>: > Excerpts from Pavel Stehule's message of mar jun 21 10:04:26 -0400 2011: >> 2011/6/21 Alvaro Herrera <alvhe...@commandprompt.com>: >> > Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011: >> > >> >> yes - it has a sense. Quoting changes sense from keyword to literal. >> >> But then I see a significant inconsistency - every know keywords >> >> should be only tokens. >> >> >> >> else if (strcmp(token, "pamservice") == 0) >> >> - { >> >> - REQUIRE_AUTH_OPTION(uaPAM, "pamservice", "pam"); >> >> - parsedline->pamservice = pstrdup(c); >> >> - } >> >> >> >> because >>pamservice<< - is known keyword, but 'pamservice' is some >> >> literal without any mean. You should to use a makro token_is_keyword >> >> more often. >> > >> > Yeah, I wondered about this too (same with auth types, i.e. do we accept >> > quoted "hostssl" and so on or should that by rejected?). I opted for >> > leaving it alone, but maybe this needs to be fixed. (Now that I think >> > about it, what we should do first is verify whether it works with quotes >> > in the unpatched code). > > I tested it and it works: This line > > "local" @dbs +b "trust" > > is accepted and it works in the unpatched code. I don't think we want > to break people's existing pg_hba.conf files for no reason. I doubt > that many people are using pg_hba.conf tokens with quotes, mind you, but > there might be some ... > > In any case, if people here thinks we should tighten this, it's easy to > do on top of this patch by changing the strcmp() calls to > token_is_keyword, as you say. Let's not burden this patch with the > responsibility of doing so, because that's likely to get it punted.
It is time to discuss about it. I thinking so current behave is strange and should be fixed - it doesn't respect a description stored in pg_hba.conf. I agree, so this will have impact on compatibility, but pg_hba is config file so this impact is not too hard. The cleaning now can carry a benefit in future, when pg_hba can be more complex. Regards Pavel -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers