Re: proposal: new polymorphic types - commontype and commontypearray
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-30T16:00:07Z
Lists: pgsql-hackers
Attachments
- polymorphics-commontype-20190130.patch (text/x-patch) patch
po 28. 1. 2019 v 20:47 odesílatel Robert Haas <robertmhaas@gmail.com> napsal: > On Fri, Jan 25, 2019 at 7:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Anyway I think the names need to be any-something. > > To me, that seems unnecessarily rigid. Not a bad idea if we can come > up with something that is otherwise acceptable. But all of your > suggestions sound worse than Pavel's proposal, so... > I implemented commontypenonarray, and commontyperange types. Now, a SQL functions are supported too. The naming is same - I had not a better idea. But it can be changed without any problems, if somebody come with some more acceptable. I don't think so the name is too important. The polymorphic types are important, interesting for extension's developers what is small group of Postgres users. And personally, I think so commontype and commontypearray are good enough for not native speakers like me. But I am opened any variant - I think so this functionality is interesting and partially coverage one gap in our implementation of polymorphic types. Regards Pavel > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
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