Re: proposal: new polymorphic types - commontype and commontypearray

Greg Stark <stark@mit.edu>

From: Greg Stark <stark@mit.edu>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, David Steele <david@pgmasters.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-10T16:59:28Z
Lists: pgsql-hackers
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.

On Tue., Mar. 5, 2019, 12:38 p.m. Pavel Stehule, <pavel.stehule@gmail.com>
wrote:

>
>
> út 5. 3. 2019 v 15:35 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>
>> David Steele <david@pgmasters.net> writes:
>> > This thread has been very quiet for a month.  I agree with Andres [1]
>> > that we should push this to PG13.
>>
>> I think the main thing it's blocked on is disagreement on what the
>> type name should be, which is kind of a silly thing to get blocked on,
>> but nonetheless it's important ...
>>
>
> I sent some others possible names, but probably this mail was forgotten
>
> What about "ctype" like shortcut for common type? carraytype,
> cnonarraytype?
>
> Regards
>
> Pavel
>
>>
>>                         regards, tom lane
>>
>

Commits

  1. Introduce "anycompatible" family of polymorphic types.

  2. Refactor our checks for valid function and aggregate signatures.

  3. Rearrange pseudotypes.c to get rid of duplicative code.