I've thought of another area that AFAICT the current patch fails to address at all: what should happen in user-defined functions? Consider
create function my_lt(x text, y text) returns bool as $$ begin return x < y; end $$ language plpgsql; select my_lt('foo', 'bar' collate "de_DE"); select my_lt('foo', 'bar' collate "fr_FR"); I think it's at least arguably desirable that the results of the two calls respond to the collation clauses, but it does not look to me like that will happen: plpgsql isn't doing anything to propagate its call-site collation value into expressions it evaluates, and if it did, it'd still get the wrong answer on the second call because it would have cached an expression plan tree containing the collation info from the first call. In SQL-language functions the situation is even worse, because they will behave differently depending on whether or not they get inlined. (I think ... haven't really tested that case.) What do we want to do about this? Making it work the way it seems like it ought to will require a rather substantial investment of effort. It looks to me like the least invasive answer would be to have plpgsql cache different plan trees depending on the collation it receives for its parameters, but that's still a whole lot of work. Does the SQL standard have anything to say on the matter, or is there a precedent in the behavior of TSQL or other DBMSes? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers