diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-10-26 13:47:45 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-10-26 13:47:45 -0400 |
| commit | 37a795a60b4f4b1def11c615525ec5e0e9449e05 (patch) | |
| tree | a5aa9d7e51ef4fd0e353223bd691f7e85018a032 /src/backend/optimizer | |
| parent | 08f1e1f0a47b4b0e87b07b9794698747b279c711 (diff) | |
Support domains over composite types.
This is the last major omission in our domains feature: you can now
make a domain over anything that's not a pseudotype.
The major complication from an implementation standpoint is that places
that might be creating tuples of a domain type now need to be prepared
to apply domain_check(). It seems better that unprepared code fail
with an error like "<type> is not composite" than that it silently fail
to apply domain constraints. Therefore, relevant infrastructure like
get_func_result_type() and lookup_rowtype_tupdesc() has been adjusted
to treat domain-over-composite as a distinct case that unprepared code
won't recognize, rather than just transparently treating it the same
as plain composite. This isn't a 100% solution to the possibility of
overlooked domain checks, but it catches most places.
In passing, improve typcache.c's support for domains (it can now cache
the identity of a domain's base type), and rewrite the argument handling
logic in jsonfuncs.c's populate_record[set]_worker to reduce duplicative
per-call lookups.
I believe this is code-complete so far as the core and contrib code go.
The PLs need varying amounts of work, which will be tackled in followup
patches.
Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
Diffstat (limited to 'src/backend/optimizer')
| -rw-r--r-- | src/backend/optimizer/util/clauses.c | 10 |
1 files changed, 8 insertions, 2 deletions
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c index 79613622805..5344f6167a6 100644 --- a/src/backend/optimizer/util/clauses.c +++ b/src/backend/optimizer/util/clauses.c @@ -2356,6 +2356,10 @@ CommuteRowCompareExpr(RowCompareExpr *clause) * is still what it was when the expression was parsed. This is needed to * guard against improper simplification after ALTER COLUMN TYPE. (XXX we * may well need to make similar checks elsewhere?) + * + * rowtypeid may come from a whole-row Var, and therefore it can be a domain + * over composite, but for this purpose we only care about checking the type + * of a contained field. */ static bool rowtype_field_matches(Oid rowtypeid, int fieldnum, @@ -2368,7 +2372,7 @@ rowtype_field_matches(Oid rowtypeid, int fieldnum, /* No issue for RECORD, since there is no way to ALTER such a type */ if (rowtypeid == RECORDOID) return true; - tupdesc = lookup_rowtype_tupdesc(rowtypeid, -1); + tupdesc = lookup_rowtype_tupdesc_domain(rowtypeid, -1, false); if (fieldnum <= 0 || fieldnum > tupdesc->natts) { ReleaseTupleDesc(tupdesc); @@ -5005,7 +5009,9 @@ inline_set_returning_function(PlannerInfo *root, RangeTblEntry *rte) * * If the function returns a composite type, don't inline unless the check * shows it's returning a whole tuple result; otherwise what it's - * returning is a single composite column which is not what we need. + * returning is a single composite column which is not what we need. (Like + * check_sql_fn_retval, we deliberately exclude domains over composite + * here.) */ if (!check_sql_fn_retval(func_oid, fexpr->funcresulttype, querytree_list, |