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
> brute force approach of
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
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 RTE,
> > >> keeping the lookups cheap.
> >
> > > Hmm,
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 the XMLTABLE patch too. I
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 straightforward, and I think
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 the XMLTABLE patch too. I ta
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 coltyp
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 talked
> a bit about it at
>
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
https://www.postgresql.org/message
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
> branches. I don't real
Kyotaro HORIGUCHI writes:
> At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston"
> wrote in
>
>> If every row passes you can retain the typemod. That is arguably the
>> ​perfect solution. The concern is that "scan every row" could be very
>> expensive - though in writing this I'm thinking
Hello,
At Mon, 5 Dec 2016 21:54:08 -0700, "David G. Johnston"
wrote in
> 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
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 solut
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 zrvf9qia0wwt_qzmauy...
Hello,
At Mon, 5 Dec 2016 18:59:42 -0700, "David G. Johnston"
wrote in
> 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 > v8nr
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 wrote:
> >
>
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 throw away typmod information
Hello,
At Mon, 5 Dec 2016 14:42:39 -0700, "David G. Johnston"
wrote in
> 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
> >
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 there are two plausible definitions:
> >> 1. If all the expressions
"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 VALUES column share the same typmod,
>> use that typm
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 of a column of a VALUE
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 corres
22 matches
Mail list logo