Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, it seems to me to work as expected. At Thu, 08 Dec 2016 15:58:10 -0500, Tom Lane wrote in <7083.1481230...@sss.pgh.pa.us> > I've pushed the previous patch to HEAD. Attached is a proposed patch > (against 9.6) that we could use for the back branches; it takes the >

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

I've pushed the previous patch to HEAD. Attached is a proposed patch (against 9.6) that we could use for the back branches; it takes the brute force approach of just computing the correct value on-demand in the two functions at issue. The key question of course is whether this is acceptable from

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

2016-12-08 14:03 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > Alvaro Herrera writes: > > > Tom Lane wrote: > > >> In HEAD, we could change the RTE data structure so that > > >> transformValuesClause could save the typmod information in the

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> In HEAD, we could change the RTE data structure so that > >> transformValuesClause could save the typmod information in the RTE, > >> keeping the lookups cheap. > > > Hmm, I think this would be useful for

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

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 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

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

2016-12-07 22:17 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > > In HEAD, we could change the RTE data structure so that > > transformValuesClause could save the typmod information in the RTE, > > keeping the lookups cheap. > > Hmm, I think this would be useful for

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

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

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Alvaro Herrera writes: > Tom Lane wrote: >> In HEAD, we could change the RTE data structure so that >> transformValuesClause could save the typmod information in the RTE, >> keeping the lookups cheap. > Hmm, I think this would be useful for the XMLTABLE patch too. I

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Tom Lane wrote: > In HEAD, we could change the RTE data structure so that > transformValuesClause could save the typmod information in the RTE, > keeping the lookups cheap. Hmm, I think this would be useful for the XMLTABLE patch too. I talked a bit about it at

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Wed, Dec 7, 2016 at 1:03 PM, Tom Lane 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 >

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Kyotaro HORIGUCHI writes: > At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston" > wrote in >

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston" wrote in

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 9:54 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > The concern is that "scan every row" could be very expensive - though in > writing this I'm thinking that you'd quickly find a non-match even in a > large dataset - and so a less perfect but still valid

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

feel free to s/typemod/typmod/ ... my fingers don't want to drop the "e" On Mon, Dec 5, 2016 at 9:17 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Mon, 5 Dec 2016 18:59:42 -0700, "David G. Johnston" < > david.g.johns...@gmail.com> wrote in

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, At Mon, 5 Dec 2016 18:59:42 -0700, "David G. Johnston" wrote in

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 6:36 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Mon, 5 Dec 2016 14:42:39 -0700, "David G. Johnston" < > david.g.johns...@gmail.com> wrote in v8nr0FsCFrQ=oo1dkp...@mail.gmail.com> > > On Mon, Dec 5, 2016 at 2:22 PM, Tom Lane

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On 6 December 2016 at 04:52, David G. Johnston wrote: > Can we be precise enough to perform #2 if the top-level (or immediate > parent) command is an INSERT - the existing table is going to enforce its > own typemod anyway, otherwise go with #1? We already routinely

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, At Mon, 5 Dec 2016 14:42:39 -0700, "David G. Johnston" wrote in

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 2:22 PM, Tom Lane wrote: > "David G. Johnston" writes: > > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: > >> In order to fix this, we first have to decide what the semantics ought > >> to be. I think

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

"David G. Johnston" writes: > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: >> In order to fix this, we first have to decide what the semantics ought >> to be. I think there are two plausible definitions: >> 1. If all the expressions in the

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: > I looked into the issue reported in bug #14448, > https://www.postgresql.org/message-id/20161205143037. > 4377.60754%40wrigleys.postgresql.org > > The core of it seems to be that expandRTE() will report the type and > typmod

[HACKERS] Typmod associated with multi-row VALUES constructs

I looked into the issue reported in bug #14448, https://www.postgresql.org/message-id/20161205143037.4377.60754%40wrigleys.postgresql.org The core of it seems to be that expandRTE() will report the type and typmod of a column of a VALUES construct as being exprType() and exprTypmod() of the