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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers