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
implement-SASLprep-4.patch.gz
Description: application/gzip
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
