Re: proposal: new polymorphic types - commontype and commontypearray
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Greg Stark <stark@mit.edu>,
David Steele <david@pgmasters.net>,
Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-14T13:26:38Z
Lists: pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes: > pá 13. 3. 2020 v 23:42 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal: >> The reason that this might be controversial is that it forces a slightly >> less precise error detail message to be issued, since the call site that's >> throwing the error doesn't know exactly which rule was being violated. >> (For example, before there was a specific error message about anyrange >> result requiring an anyrange input, and now there isn't.) > Unfortunately the error message " A function returning "anyrange" must have > at least one "anyrange" argument." will be missing. Yeah, that's what I said. But does it really add anything beyond the proposed text "A function returning a polymorphic type must have at least one matching polymorphic argument"? I don't think it'd be terribly helpful to say "A function returning anyelement must have at least one anyelement, anyarray, anynonarray, anyenum, or anyrange argument", and for sure such an error message would be a pain to maintain. 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