Thread
Commits
-
Fix handling of container types in find_composite_type_dependencies.
- 4e704aac18d1 9.2.23 landed
- 06931a9c0e2f 9.3.19 landed
- e2e398473e3c 9.6.5 landed
- d1c1d90e1061 9.5.9 landed
- 95a0a8d2ab10 9.4.14 landed
- 749c7c41701c 10.0 landed
-
More fun with container types
Tom Lane <tgl@sss.pgh.pa.us> — 2017-08-09T20:03:44Z
While poking at the arrays-of-domains TODO item, I found yet another area in which the existing code fails to handle existing supported cases. Specifically, although DefineRange will happily take domains or composites as a range subtype, and we already noticed that domains-over-array-of- composite are supported, find_composite_type_dependencies is innocent of the idea that the target type might be embedded in anything but an array or composite type. The test cases in the attached patch show cases where HEAD either fails to notice stored data violating a proposed new domain constraint, or hits assertion failures or core dumps. The patch addresses this by generalizing the existing special case for array-over-composite so that any type that's directly dependent on the target type (which could be its array type, or a domain or range over it) is treated as a container type and recursively scanned for. I believe this coding will work without any further changes for the case of arrays over domains, but I've not fully tested that yet. I intend to apply and back-patch this shortly, unless anyone has a better idea about how to handle such cases. regards, tom lane