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-14T04:09:36Z
Lists: 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 >
Commits
-
Introduce "anycompatible" family of polymorphic types.
- 24e2885ee304 13.0 landed
-
Refactor our checks for valid function and aggregate signatures.
- e6c178b5b73a 13.0 landed
-
Rearrange pseudotypes.c to get rid of duplicative code.
- 87c9c2571c81 13.0 landed