2011/6/21 Alvaro Herrera <alvherre@commandprompt.com>:
> Excerpts from Pavel Stehule's message of mar jun 21 10:04:26 -0400 2011:
>> 2011/6/21 Alvaro Herrera <alvherre@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
