Re: [TODO] Process pg_hba.conf keywords as case-insensitive

Hi, This is revised patch including document.

I confused three identifiers to be compared, names in the
catalog, those in pg_hba lines and those given from the client
under connecting. This patch concerns the comparison between
pg_hba and client names.

Finally all the additional pg_strcasecmp() or whole catalog
scanning are eliminated. This version works as following.

Tokenize every hba tokens and categorize having two attributes,
  One is whether the case is preserved or not. Case of a word is  preserved in the returned token if the word is
enclosedwith  double quotes.
 
  Another is token type, Leading bare '+' indicates the token is  a group name, and '@' indicates file inclusion. The
stringin  returned token is stripped of the special characters.
 
  A double quoted region which does not begin at the beginning  of the word was handled in its own way from before this
change. I don't know it is right or not. (ho"r""i"guti stored  as hor"iguti by the orignal next_token() and it is not
changed)

Matching names are performed as following,
  Tokens corrensponding to keywords should be 'normal' ones (not  a group name or file inclusion) and should not be
case-preservedones, which were enclosed by double quotes. The  tokens are lowercased so token_is_keyword() macro
compares them by strcmp().
 
  Database name and user name should be 'normal' tokens and the  cases of the names are preserved or not according to
the notaion in hba line so token_matches() compares them with the  name given from client by strcmp().
 


The patch size is far reduced from the previous version.


At Wed, 10 Sep 2014 11:32:22 +0200, Florian Pflug <fgp@phlo.org> wrote in
<7D70EE06-1E80-44D6-9428-5F60AD796D26@phlo.org>
> So foo, Foo and FOO would all match the user called <foo>,
> but "Foo" would match the user called <Foo>, and "FOO" the
> user called <FOO>.

This patch does so.

> An unquoted "+" would cause whatever follows it to be interpreted
> as a group name, whereas a quoted "+" would simply become part of
> the user name (or group name, if there's an additional unquoted
> "+" before it).
> So +foo would refer to the group <foo>, +"FOO" to the group <FOO>,
> and +"+A" to the group <+A>.

I think this behaves so.

> I haven't checked if such an approach would be sufficiently
> backwards-compatible, though.

One obveous breaking which affects the existing sane pg_hba.conf
is that db and user names not surrounded by double quotes became
to match the lowercased names, not the original name containing
uppercase characters. But this is just what this patch intended.

I think all behaviors for other cases appear in existing
pg_hba.conf are unchanged including the behaviors for string
consists of single character '+' or '@'.

# '+' is treated as a group name '' and '@' is treated as a
# user/db name '@' but they seems meanless..

Any suggestions?

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center