From: | Brendan Jurd <direvus(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: Keywords in pg_hba.conf should be field-specific |
Date: | 2011-06-22 02:38:36 |
Message-ID: | BANLkTinDnChqTJQVAgq152u0k68dDnLA6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22 June 2011 00:47, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>>> 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).
>
> AFAICS, this is only important in places where the syntax allows either
> a keyword or an identifier. If only a keyword is possible, there is no
> value in rejecting it because it's quoted. And, when you do the test,
> I think you'll find that it would be breaking hba files that used to
> work (though admittedly, it's doubtful that there are any such in the
> field).
Yes, I agree, and this was my thinking when I came up against this
while writing the original patch. It doesn't help to treat "hostssl"
differently than hostssl, because quoted identifiers are meaningless
in that context.
Cheers,
BJ
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-22 02:58:21 | Re: smallserial / serial2 |
Previous Message | Robert Haas | 2011-06-22 02:37:31 | Re: deadlock_timeout at < PGC_SIGHUP? |