Re: proposal: new polymorphic types - commontype and commontypearray - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: new polymorphic types - commontype and commontypearray
Date
Msg-id CAFj8pRCq+=tdb0PA8cHXG6bppVEqRrx7gjWeO4RtXkcPieoLaw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: new polymorphic types - commontype and commontypearray  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: new polymorphic types - commontype and commontypearray  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


čt 13. 6. 2019 v 2:37 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Greg Stark <stark@mit.edu> writes:
> The proposals I see above are "commontype", "supertype", "anycommontype",
> and various abbreviations of those. I would humbly add "compatibletype".
> Fwiw I kind of like commontype.
> Alternately an argument could be made that length and typing convenience
> isn't really a factor here since database users never have to type these
> types. The only place they get written is when defining polymorphic
> functions which is a pretty uncommon operation.
> In which case a very explicit "anycompatibletype" may be better.

I could go with "anycompatibletype".  That would lead us to needing
related names like "anycompatiblearraytype", which is getting annoyingly
long, but you might be right that people wouldn't have to type it that
often.

Also, given the precedent of "anyarray" and "anyrange", it might be
okay to make these just "anycompatible" and "anycompatiblearray".

I like anycompatible and anycompatiblearray.

I'll update the patch

Regards

Pavel


[ wanders away wondering if psql can tab-complete type names in
function definitions ... ]

                        regards, tom lane

pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Index Skip Scan
Next
From: Alexander Lakhin
Date:
Subject: Re: Fix inconsistencies for v12 (pass 2)