Re: Collations versus user-defined functions

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> I think I didn't explain myself well. The *state* should be implicit,
> the actual collation should be whatever the query says. What I was
> thinking of is the following:

> CREATE FUNCTION my_english_lt(text, text) RETURNS boolean AS $$
> return $1 < $2 COLLATE "en_US"
> $$;

> (not sure about the syntax but you get the idea).

> If you just propegate naively you would get:

> my_english_lt(x COLLATE "de_DE", y) -> error, conflicting collation
> my_english_ly(x, y COLLATE "de_DE") -> would work fine

> Hence my suggestion that on input to the function the parameters would
> be considered collation "de_DE" state IMPLICIT, so the collation in the
> function overrides, but if the COLLATE in the function is removed, the
> implicit collation takes hold.

Oh, I see. Yeah, that should work correctly, because parsing inside the
function will be done with Param symbols that act pretty much like Vars
--- whatever collation they have is considered implicit. It's important
here that we do inlining by splicing completed parsetrees together ---
we *don't* do some sort of insert-the-parameters-and-reparse-from-scratch
approach. So the collation labelings made inside the function won't
change as a result of inlining.

regards, tom lane