Mmm. I did the same thing in select_common_type and resulted in a messier (a bit).
At Wed, 07 Dec 2016 23:44:19 -0500, Tom Lane <t...@sss.pgh.pa.us> wrote in <15128.1481172...@sss.pgh.pa.us> > Attached is a patch that fixes this by storing typmod info in the RTE. > This turned out to be straightforward, and I think it's definitely > what we should do in HEAD. I have mixed emotions about whether it's > worth doing anything about it in the back branches. With it, VALUES works as the same as UNION, as documentation says. https://www.postgresql.org/docs/8.2/static/queries-values.html Past versions have the same documentation so back-patching the *behavior* seems to me worth doing. Instead of modifying RTE, re-coercing the first row's value would enough (I'm not sure how to do that now) for back-patching. > I chose to redefine the existing coltypes/coltypmods/colcollations > lists for CTE RTEs as also applying to VALUES RTEs. That saves a > little space in the RangeTblEntry nodes and allows sharing code > in a couple of places. It's tempting to consider making that apply > to all RTE types, which would permit collapsing expandRTE() and > get_rte_attribute_type() into a single case. But AFAICS there would > be no benefit elsewhere, so I'm not sure the extra code churn is > justified. Agreed. > BTW, I noticed that the CTE case of expandRTE() fails to assign the > specified location to the generated Vars, which is clearly a bug > though a very minor one; it would result in failing to display a > parse error location in some cases where we would do so for Vars from > other RTE types. That part might be worth back-patching, not sure. If we do back-patching VALUES patch, involving it would worth, I think. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers