Re: Compatible defaults for LEAD/LAG - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Compatible defaults for LEAD/LAG
Date
Msg-id 10688.1590977249@sss.pgh.pa.us
Whole thread Raw
In response to Re: Compatible defaults for LEAD/LAG  (Vik Fearing <vik@postgresfriends.org>)
Responses Re: Compatible defaults for LEAD/LAG
List pgsql-hackers
Vik Fearing <vik@postgresfriends.org> writes:
> 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.

> array_replace, lead, and lag are the only functions we have that take
> more than one anyelement.

That's just the tip of the iceberg, though.  If you consider all the
old-style polymorphic types, we have

                     proc                      
-----------------------------------------------
 array_append(anyarray,anyelement)
 array_cat(anyarray,anyarray)
 array_eq(anyarray,anyarray)
 array_ge(anyarray,anyarray)
 array_gt(anyarray,anyarray)
 array_larger(anyarray,anyarray)
 array_le(anyarray,anyarray)
 array_lt(anyarray,anyarray)
 array_ne(anyarray,anyarray)
 array_position(anyarray,anyelement)
 array_position(anyarray,anyelement,integer)
 array_positions(anyarray,anyelement)
 array_prepend(anyelement,anyarray)
 array_remove(anyarray,anyelement)
 array_replace(anyarray,anyelement,anyelement)
 array_smaller(anyarray,anyarray)
 arraycontained(anyarray,anyarray)
 arraycontains(anyarray,anyarray)
 arrayoverlap(anyarray,anyarray)
 btarraycmp(anyarray,anyarray)
 elem_contained_by_range(anyelement,anyrange)
 lag(anyelement,integer,anyelement)
 lead(anyelement,integer,anyelement)
 range_adjacent(anyrange,anyrange)
 range_after(anyrange,anyrange)
 range_before(anyrange,anyrange)
 range_cmp(anyrange,anyrange)
 range_contained_by(anyrange,anyrange)
 range_contains(anyrange,anyrange)
 range_contains_elem(anyrange,anyelement)
 range_eq(anyrange,anyrange)
 range_ge(anyrange,anyrange)
 range_gist_same(anyrange,anyrange,internal)
 range_gt(anyrange,anyrange)
 range_intersect(anyrange,anyrange)
 range_le(anyrange,anyrange)
 range_lt(anyrange,anyrange)
 range_merge(anyrange,anyrange)
 range_minus(anyrange,anyrange)
 range_ne(anyrange,anyrange)
 range_overlaps(anyrange,anyrange)
 range_overleft(anyrange,anyrange)
 range_overright(anyrange,anyrange)
 range_union(anyrange,anyrange)
 width_bucket(anyelement,anyarray)
(45 rows)

(I ignored anyenum here, since it has no mapping to the anycompatible
family.)  Some of these are internal or can otherwise be discounted,
but surely there'd be a market for, say, "int8[] || int4".  The big
question that raises is can we do it without creating impossible confusion
with text-style concatenation.

> Are you sure we don't want to give
> at least the anycompatible type a nice public workout with this?

Yes, I'm quite sure.  If the idea crashes and burns for some reason,
we'll be glad we didn't buy into it full-speed-ahead right away.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: segmentation fault using currtid and partitioned tables
Next
From: Michael Paquier
Date:
Subject: Re: segmentation fault using currtid and partitioned tables