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 23:30:21 |
Message-ID: | 4f100140-f08a-5c1d-8c1b-2ae412a7b860@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:
> 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.
BTW, I did go through pg_proc.dat to see what we've got and these were
the only two I found. I mentioned that in a part you didn't quote. Now
I went through again, this time using a query on pg_proc itself, and I
missed array_replace during my manual scan.
array_replace, lead, and lag are the only functions we have that take
more than one anyelement.
There are many functions (seemingly all operator implementations) that
take multiple anyarray, anyrange, and anyenum; but none with anynonarray
and only those three for anyelement. Are you sure we don't want to give
at least the anycompatible type a nice public workout with this?
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2020-06-01 01:00:25 | Re: Default gucs for EXPLAIN |
Previous Message | Bossart, Nathan | 2020-05-31 22:28:30 | Re: archive status ".ready" files may be created too early |