Re: Typmod associated with multi-row VALUES constructs
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-12-07T20:16:18Z
Lists: pgsql-hackers
On Wed, Dec 7, 2016 at 1:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Still, things have been like this since 8.2 when we implemented multi-row > VALUES, and nobody's noticed up to now. Maybe the right answer is to > change the data structure in HEAD and decree that we won't fix it in back > branches. I don't really like that answer though ... > The merit of "won't back-patch" is that at least you don't punish those who are being lazy (in a good sense) but generating values in subsequent lines that conform to the type specification of the first record. We already implicitly accept such behavior elsewhere - though probably with better validation - so keeping it here is defense-able. We dislike changing query plans in back branches and this really isn't that different. The concern, especially since this can propagate to a CREATE TABLE AS, is whether there is some kind of fundamental storage risk being introduced that we do not want to have happen no matter how rare. /me feels deja-vu... David J.
Commits
-
Fix reporting of column typmods for multi-row VALUES constructs.
- cf22c8cb8900 9.6.2 landed
- c7a62135acfb 9.4.11 landed
- 6a493adda745 9.5.6 landed
- 2afe282a3732 9.3.16 landed
- 082d1fb9e4ec 9.2.20 landed
- 0b78106cd465 10.0 landed