Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Wild idea: we have quite a few functions (e.g. date_trunc, date_part,
> timezone, encode, decode, make_timestamptz, plus various extension
> functions such as in pgcrypto) that take a "text" parameter which is
> nothing more than a poor-man's enum, or otherwise represents something
> which isn't actually free text. Perhaps these should use "name" instead,
> or in some cases an enum type?
Hm. It'd definitely be cool if constant text parameters could be
const-folded to some enum-like representation, so that at runtime these
functions would just do integer comparisons rather than string comparisons
to decide what to do. Not sure about the backwards compatibility
considerations though.
However, that could only fix the OP's problem for these particular
functions, which are a small fraction of the ones we have that take
collatable types but don't really care about collation. I kinda feel
like we should have invented an "ignores collation" function property,
so that such functions could be identified --- that would not only let
postgres_fdw handle this honestly, but we could refrain from throwing
unmatched-collations errors for cases where it doesn't really matter.
Maybe it's not too late to invent that in future. If the parser sets
inputcollid = 0 for any function marked that way, then if the function is
incorrectly marked as ignoring collation it would get an error at runtime,
so it seems like we could add it safely.
> (or in the case of date_trunc and extract, maybe they need to be split
> up into separate functions so that we can properly distinguish the
> immutable from the mutable cases)
Different issue ... and not actually relevant to this case, since
this form of date_trunc is immutable.
regards, tom lane
