forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit77ec5af
committed
Adjust handling of an ANYARRAY actual input for an ANYARRAY argument.
Ordinarily it's impossible for an actual input of a function to havedeclared type ANYARRAY, since we'd resolve that to a concrete arraytype before doing argument type resolution for the function. But anexception arises for functions applied to certain columns of pg_statisticor pg_stats, since we abuse the "anyarray" pseudotype by using it todeclare those columns. So parse_coerce.c has to deal with the case.Previously we allowed an ANYARRAY actual input to match an ANYARRAYpolymorphic argument, but only if no other argument or result wasdeclared ANYELEMENT. When that logic was written, those were the onlytwo polymorphic types, and I fear nobody thought carefully about how itought to extend to the other ones that came along later. But actuallyit was wrong even then, because if a function has two ANYARRAYarguments, it should be able to expect that they have identical elementtypes, and we'd not be able to ensure that.The correct generalization is that we can match an ANYARRAY actual inputto an ANYARRAY polymorphic argument only if no other argument or resultis of any polymorphic type, so that no promises are being made aboutelement type compatibility. check_generic_type_consistency can't testthat condition, but it seems better anyway to accept such matches thereand then throw an error if needed in enforce_generic_type_consistency.That way we can produce a specific error message rather than anunintuitive "function does not exist" complaint. (There's some riskperhaps of getting new ambiguous-function complaints, but I think thatany set of functions for which that could happen would be ambiguousagainst ordinary array columns as well.) While we're at it, we canimprove the message that's produced in cases that the code did alreadyobject to, as shown in the regression test changes.Also, remove a similar test that got cargo-culted in for ANYRANGE;there are no catalog columns of type ANYRANGE, and I hope we nevercreate any, so that's not needed. (It was incomplete anyway.)While here, update some comments and rearrange the code a bit inpreparation for upcoming additions of more polymorphic types.In practical situations I believe this is just exchanging one errormessage for another, hopefully better, one. So it doesn't seemneedful to back-patch, even though the mistake is ancient.Discussion:https://postgr.es/m/21569.1584314271@sss.pgh.pa.us1 parent5d0c2d5 commit77ec5af
File tree
3 files changed
+191
-186
lines changed- src
- backend/parser
- test/regress/expected
3 files changed
+191
-186
lines changed0 commit comments
Comments
(0)