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 <tgl@sss.pgh.pa.us> wrote in <15128.1481172259@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
