Re: analyzeCTE is too strict about typmods?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: analyzeCTE is too strict about typmods?
Date: 2017-09-22 05:52:53
Message-ID: 20170922.145253.225468893.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 03 Aug 2017 19:29:40 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <28993(dot)1501802980(at)sss(dot)pgh(dot)pa(dot)us>
> I wrote:
> > In short, therefore, it's looking to me like analyzeCTE() is wrong here.
> > It should allow the case where the recursive result has typmod -1 while
> > the non-recursive output column has some more-specific typmod, so long
> > as they match on type OID. That would correspond to what we do in
> > regular non-recursive UNION situations.
>
> Oh, scratch that. I was thinking that we could simply relax the error
> check, but that really doesn't work at all. The problem is that by now,
> we have probably already generated Vars referencing the outputs of the
> recursive CTE, and those will have the more-specific typmod, which is
> wrong in this scenario. Usually that wouldn't matter too much, but
> there are cases where it would matter.
>
> We could imagine dealing with this by re-parse-analyzing the recursive
> term using typmod -1 for the CTE output column, but I don't much want
> to go there. It wouldn't be cheap, and I'm not quite sure it's guaranteed
> to converge anyway.

Agreed.

> What's seeming like an attractive compromise is to change the HINT
> to recommend manually coercing the recursive term, instead of the
> non-recursive one. Adjusting the error cursor to point to that side
> might be a bit painful, but it's probably doable.
>
> Thoughts?

I agree to the direction, but if I'm not missing anything
transformSetOperationTree has the enough information and we won't
get the expected pain there. (The movement itself might be the
pain, though..)

| ERROR: recursive query "foo" column 1 has type numeric(7,3) in non-recursive term but type numeric overall
| LINE 4: select f1+1 from foo
| ^
| HINT: Cast the output of the recursive term to the type of the non-recursive term.

# The hint gets a bit longer..

By the way a wrong collation still results in the previous hint
but it won't be a problem.

| ERROR: recursive query "foo" column 1 has collation "it_IT" in non-recursive term but collation "ja_JP" overall
| LINE 2: select a from bar
| ^
| HINT: Use the COLLATE clause to set the collation of the non-recursive term.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
recurseivecte_errmsg.patch text/x-patch 6.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2017-09-22 05:57:02 Re: UPDATE of partition key
Previous Message Rafia Sabih 2017-09-22 05:15:47 Re: Partition-wise join for join between (declaratively) partitioned tables