Re: analyzeCTE is too strict about typmods?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: analyzeCTE is too strict about typmods?
Date: 2017-08-03 23:29:40
Message-ID: 28993.1501802980@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-08-04 00:45:05 Re: A bug in mapping attributes in ATExecAttachPartition()
Previous Message Tom Lane 2017-08-03 22:50:45 analyzeCTE is too strict about typmods?