You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Fix reporting of column typmods for multi-row VALUES constructs.
expandRTE() and get_rte_attribute_type() reported the exprType() andexprTypmod() values of the expressions in the first row of the VALUES asbeing the column type/typmod returned by the VALUES RTE. That's fine forthe data type, since we coerce all expressions in a column to have the samecommon type. But we don't coerce them to have a common typmod, so it waspossible for rows after the first one to return values that violate theclaimed column typmod. This leads to the incorrect result seen in bug#14448 from Hassan Mahmood, as well as some other corner-case misbehaviors.The desired behavior is the same as we use in other type-unificationcases: report the common typmod if there is one, but otherwise return -1indicating no particular constraint. It's cheap for transformValuesClauseto determine the common typmod while transforming a multi-row VALUES, butit'd be less cheap for expandRTE() and get_rte_attribute_type() tore-determine that info every time they're asked --- possibly a lot lesscheap, if the VALUES has many rows. Therefore, the best fix is to recordthe common typmods explicitly in a list in the VALUES RTE, as we werealready doing for column collations. This looks quite a bit like whatwe're doing for CTE RTEs, so we can save a little bit of space and code byunifying the representation for those two RTE types. They both now sharecoltypes/coltypmods/colcollations fields. (At some point it might seemdesirable to populate those fields for all RTE types; but right now itlooks like constructing them for other RTE types would add more code andcycles than it would save.)The RTE change requires a catversion bump, so this fix is only usablein HEAD. If we fix this at all in the back branches, the patch willneed to look quite different.Report:https://postgr.es/m/20161205143037.4377.60754@wrigleys.postgresql.orgDiscussion:https://postgr.es/m/27429.1480968538@sss.pgh.pa.us