Compatible defaults for LEAD/LAG

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Compatible defaults for LEAD/LAG
Date: 2020-05-31 17:20:10
Message-ID: 77675130-89da-dab1-51dd-492c93dcf5d1@postgresfriends.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I noticed that the PostgreSQL entry in a pan-database feature matrix by
Modern SQL was not reflecting the reality of our features.[1]

It turns out that test case used by the author produced an error which
the tool took to mean the feature was not implemented. I don't have the
actual test, but here is a simulation of it:

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)
^
HINT: No function matches the given name and argument types. You
might need to add explicit type casts.

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.

I looked for other functions with a similar issue but didn't find any.

[1] https://twitter.com/pg_xocolatl/status/1266694496194093057
--
Vik Fearing

Attachment Content-Type Size
lead_lag_compatible_default.diff text/x-patch 6.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-05-31 17:31:14 Re: Proposal: remove string "contains errors; unaffected changes were applied"
Previous Message Martín Marqués 2020-05-31 15:13:08 Re: Read access for pg_monitor to pg_replication_origin_status view