Re: Collations versus user-defined functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Collations versus user-defined functions
Date
Msg-id 2528.1299966876@sss.pgh.pa.us
Whole thread Raw
In response to Re: Collations versus user-defined functions  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: template0 database comment
Next
From: "Aaron W. Swenson"
Date:
Subject: Re: pg_dump -X