On Sep10, 2014, at 10:54 , Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> 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.
That does indeed sound bad. Couldn't we handle this the same
way we handle SQL identifiers, i.e. simply downcase unquoted
identifiers, and then compare case-sensitively?
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>.
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 haven't checked if such an approach would be sufficiently
backwards-compatible, though.
best regards,
Florian Pflug