On Sep10, 2014, at 10:54 , Kyotaro HORIGUCHI <horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
