From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-07 20:16:18 |
Message-ID: | CAKFQuwYpBgMQvH-HZCfL3ske2fnav-omR1Oc9H8RGLPxsaw3XA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 7, 2016 at 1:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-07 20:21:34 | Re: [COMMITTERS] pgsql: Implement table partitioning. |
Previous Message | Tom Lane | 2016-12-07 20:13:46 | Re: [COMMITTERS] pgsql: Implement table partitioning. |