From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Compatible defaults for LEAD/LAG |
Date: | 2020-05-31 20:02:29 |
Message-ID: | 334fb293-6565-a4cd-dd06-1058d6dc9a5c@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5/31/20 9:53 PM, Tom Lane wrote:
> Vik Fearing <vik(at)postgresfriends(dot)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.
Fair enough. I put it in the commitfest app for version 14.
https://commitfest.postgresql.org/28/2574/
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2020-05-31 21:11:35 | Re: race condition when writing pg_control |
Previous Message | Tom Lane | 2020-05-31 19:53:21 | Re: Compatible defaults for LEAD/LAG |