Vik Fearing <v...@postgresfriends.org> writes:
> postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY n)
> postgres-# FROM (VALUES (1.1), (2.2), (3.3)) AS v (n)
> postgres-# ORDER BY n;
> ERROR: function lag(numeric, integer, integer) does not exist
> LINE 1: SELECT LAG(n, 1, -99) OVER (ORDER BY n)
> ^
Yeah, we have similar issues elsewhere.
> Attached is a patch that fixes this issue using the new anycompatible
> pseudotype. I am hoping this can be slipped into 13 even though it
> requires a catversion bump after BETA1.
When the anycompatible patch went in, I thought for a little bit about
trying to use it with existing built-in functions, but didn't have the
time to investigate the issue in detail. I'm not in favor of hacking
things one-function-at-a-time here; we should look through the whole
library and see what we've got.
The main thing that makes this perhaps-not-trivial is that an
anycompatible-ified function will match more cases than it would have
before, possibly causing conflicts if the function or operator name
is overloaded. We'd have to look at such cases and decide what we
want to do --- one answer would be to drop some of the alternatives
and rely on the parser to add casts, but that might slow things down.
Anyway, I agree that this is a good direction to pursue, but not in
a last-minute-hack-for-v13 way.
regards, tom lane
