Re: proposal: new polymorphic types - commontype and commontypearray

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <stark@mit.edu>, David Steele <david@pgmasters.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-17T03:31:40Z
Lists: pgsql-hackers

Attachments

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
>>
>

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.