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

Hello, I had a closer look on this patch.

Finally I think that we need case-insensitive version of
get_role_id and() get_database_id() to acoomplish this patch'es
objective. (This runs full-scans on pg_database or pg_authid X()

And I'd like to propose to change token categorization from
notation-base to how-to-treat base. Concretely this patch
categorizes tokens using 'special quote is used' and 'quote from
the first' but it seems making logics clearer to categorize them
using 'case sensive or not' and 'it represents group name'.

The attached patch is a revised version of your original patch
regarding to the above point. (Sorry in advance that this is a
quick hack, especially the code related to file-inclusion is not
tested at all)

I have tested this only superficial level but it seems works as
expected.

Under the new specifications, next_token will work as following,

- USER : token: USER , case-insensitive
- "USeR" : token: USeR , case-SENSITIVE
- "+uSeR" : token: +uSeR , case-SENSITIVE
- "+UsE"R : token: +UsEr , case-insensitive
- U"S""e"R : token: US"eR , case-insensitive

- +USER : token: USER , case-insensitive, group_name
- +"uSeR" : token: uSeR , case_SENSITIVE, group_name
- +U"sE""r" : token: UsE"r , case-insensitive, group_name

- + : token: + , (useless?)
- @ : token: @ , (useless?)
- @ho"ge : token: ho"ge, file_inclusion (not confirmed)

There's a concern that Case-insensitive matching is accomplished
by full-scan on pg_database or pg_authid so it would be rather
slow than case-sensitive matching. This might not be acceptable
by the community.

And one known defect is that you will get a bit odd message if
you put an hba line having keywords quoted or prefixed with '+',
for example

+locAl "postgres" +sUs tRust

The server complains for the line above that

*| LOG: invalid connection type "locAl"
| CONTEXT: line 84 of configuration file "/home/horiguti/data/data_work/pg_hba.conf"

The prefixing '+' is omitted. To correct this, either deparsing
token into original string or storing original string into tokens
is needed, I think.

What do you think about the changes, Viswanatham or all ?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center