Collations versus user-defined functions

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