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 CAFj8pRD0EJ0iEWK=eDfkrFmirp_OWAiTtaqKXuGZ=QUaJzVAHg@mail.gmail.com
Whole thread Raw
In response to Re: proposal: new polymorphic types - commontype and commontypearray  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: new polymorphic types - commontype and commontypearray
List pgsql-hackers
Hi

pá 14. 6. 2019 v 6:09 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:


č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

and here it is

Regards

Pavel
 

Regards

Pavel


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

                        regards, tom lane
Attachment

pgsql-hackers by date:

Previous
From: Shawn Wang
Date:
Subject: Re: Problem with default partition pruning
Next
From: Paul A Jungwirth
Date:
Subject: Re: SQL:2011 PERIODS vs Postgres Ranges?