Another version attached.
I think this is now in committable state, but there's been a lot of
small changes here and there, so please have one more look over it if
you have a chance. I'm planning to push this tomorrow, after sleeping on it.
The code-organization issue with the utf8 functions, pg_utf_mblen,
pg_utf8_islegal, unicode_to_utf8, and utf8_to_unicode, is still kind of
unresolved. The way I have it in this version is that the functions are
in wchar.c, like they've always been, and saslprep.c uses them from
there. This is ugly from a code organization point of view. as we now
have functions in src/common depending on functions in
src/backend/utils/mb/wchar.c. I think wchar.c deserves some
re-organization, as most of the functions there are also used in
frontend code. Perhaps it should be moved to src/common as whole.
Libpq already compiles with wchar.c, so all those functions that
src/common/saslprep.c requires are already available in libpq. So I
don't think that's urgent, but something we nevertheless ought to clean
up at some point.
Another thing I'd like some more eyes on, is how this will work with
encodings other than UTF-8. We will now try to normalize the password as
if it was in UTF-8, even if it isn't. That's OK as long as we're
consistent about it, but there is one worrisome scenario: what if the
user's password consists mostly of characters, that when interpreted as
UTF-8, are in the list of ignored characters. IOW, is it realistic that
a user might have a password in a non-UTF-8 encoding, that gets silently
mangled into something much shorter? I think that's highly unlikely, but
can anyone come up with a plausible example of that?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
