Re: proposal: new polymorphic types - commontype and commontypearray

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: new polymorphic types - commontype and commontypearray
Date: 2019-06-13 00:37:21
Message-ID: 29550.1560386241@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)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".

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

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-06-13 00:46:57 Re: pg_dump: fail to restore partition table with serial type
Previous Message Bruce Momjian 2019-06-13 00:22:03 Re: PG 12 draft release notes