Martijn van Oosterhout <klep...@svana.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
