From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Typmod associated with multi-row VALUES constructs |
Date: | 2016-12-08 04:44:19 |
Message-ID: | 15128.1481172259@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-VALUES-RTE-typmods.patch | text/x-diff | 22.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-12-08 05:33:23 | Re: Typmod associated with multi-row VALUES constructs |
Previous Message | Michael Paquier | 2016-12-08 04:42:32 | Re: Declarative partitioning - another take |