On 05.06.25 21:56, Jeff Davis wrote:
> On Thu, 2025-06-05 at 10:12 +0200, Peter Eisentraut wrote:
>> The reason we don't do it at parse time is that we don't have the
>> information which functions care about collations, which is exactly
>> what
>> you are proposing here to add.
>
> Currently, we have:
>
> create table c(x text collate "C", y text collate "en_US");
> insert into c values ('x', 'y');
> select x < y from c; -- fails (runtime check)
> select x || y from c; -- succeeds
>
> Surely, "<" would be marked as ordering-sensitive, and we could move
> the error to parse-time.
>
> But what about UDFs? If we assume that all UDFs are ordering-sensitive
> unless marked otherwise, then a user-defined version of "||" that
> previously worked would now start failing, until they add the ordering-
> insensitive mark.
I think no matter how we slice it, there is going to be some case that
will be degraded until some update is applied. I would be content to
accept this particular variant, because it doesn't seem very realistic.
Why would a user define their own concatenation function? There already
is one. Unless your concatenation function does something special, in
which case you should probably think about this collations topic. More
generally, there are I think only so many operations you can do on
characters strings that you can do without considering the
collation/ctype/etc. These are essentially all the operations that you
can do without looking at the characters, like length(), ||, repeat().
Everything beyond that looks at the characters and needs to take
collation/ctype/etc. into account.
> We'd need some kind of migration path where we could retain the runtime
> checks and disable the parse time checks until people have a chance to
> add the right marks to their UDFs. Migration paths like that are not
> great because they take several releases to work out, and we're never
> quite sure when to finally remove the deprecated behavior.
Perhaps pg_dump can apply some properties during upgrades?
> If we make the opposite assumption, that none are ordering-sensitive
> unless we mark them so, that would allow properly-marked functions to
> fail at parse time, and the rest to fail at runtime. But this
> assumption doesn't work as well for recording dependencies, because
> we'd miss the dependencies for UDFs that aren't properly marked.
That feels like the worst of both worlds.
