Re: [HACKERS] analyzeCTE is too strict about typmods?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] analyzeCTE is too strict about typmods?
Дата
Msg-id 28993.1501802980@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] analyzeCTE is too strict about typmods?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] analyzeCTE is too strict about typmods?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: [HACKERS] analyzeCTE is too strict about typmods?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()