pgsql: Restructure polymorphic-type resolution in funcapi.c.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Restructure polymorphic-type resolution in funcapi.c.
Дата
Msg-id E1jDBkH-0000cG-Nb@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Restructure polymorphic-type resolution in funcapi.c.

resolve_polymorphic_tupdesc() and resolve_polymorphic_argtypes() failed to
cover the case of having to resolve anyarray given only an anyrange input.
The bug was masked if anyelement was also used (as either input or
output), which probably helps account for our not having noticed.

While looking at this I noticed that resolve_generic_type() would produce
the wrong answer if asked to make that same resolution.  ISTM that
resolve_generic_type() is confusingly defined and overly complex, so
rather than fix it, let's just make funcapi.c do the specific lookups
it requires for itself.

With this change, resolve_generic_type() is not used anywhere, so remove
it in HEAD.  In the back branches, leave it alone (complete with bug)
just in case any external code is using it.

While we're here, make some other refactoring adjustments in funcapi.c
with an eye to upcoming future expansion of the set of polymorphic types:

* Simplify quick-exit tests by adding an overall have_polymorphic_result
flag.  This is about a wash now but will be a win when there are more
flags.

* Reduce duplication of code between resolve_polymorphic_tupdesc() and
resolve_polymorphic_argtypes().

* Don't bother to validate correct matching of anynonarray or anyenum;
the parser should have done that, and even if it didn't, just doing
"return false" here would lead to a very confusing, off-point error
message.  (Really, "return false" in these two functions should only
occur if the call_expr isn't supplied or we can't obtain data type
info from it.)

* For the same reason, throw an elog rather than "return false" if
we fail to resolve a polymorphic type.

The bug's been there since we added anyrange, so back-patch to
all supported branches.

Discussion: https://postgr.es/m/6093.1584202130@sss.pgh.pa.us

Branch
------
REL_12_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/390984f92696712fe783609cabbc79f58d0f8a7d

Modified Files
--------------
src/backend/utils/fmgr/funcapi.c         | 323 ++++++++++++++++++-------------
src/test/regress/expected/rangetypes.out |  23 ++-
src/test/regress/sql/rangetypes.sql      |  14 +-
3 files changed, 216 insertions(+), 144 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: pgsql: Use multi-variate MCV lists to estimate ScalarArrayOpExpr
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Rearrange pseudotypes.c to get rid of duplicative code.