Re: Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE
От | Tom Lane |
---|---|
Тема | Re: Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE |
Дата | |
Msg-id | 20096.1464032918@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Re: [BUGS] BUG #14153: Unrecognized node type error
when upsert is present in recursive CTE
|
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > On Mon, May 23, 2016 at 12:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> It seems unlikely to me that recursing into the name lists is helpful >> here: those are not going to contain any data that is interpretable >> without context. Did you have a reason to do that? > I saw no reason to avoid the extra cycles. A noticeable omission has a > cost: it gets noticed. Given this code path is likely to hardly ever > be hit, this mechanical approach seemed best. That's all. I agree that performance isn't much of a concern, but code bloat and inconsistency with other cases are valid concerns. That function does not recurse into name lists in, for example, the A_Expr and FuncCall cases. Also, related to this complaint though not this patch, it's disturbing that this oversight wasn't detected long ago. My first thought was to add some conditionally-compiled debugging code that just performs a no-op traverse of every raw parse tree produced by the grammar. However that doesn't work because raw_expression_tree_walker doesn't promise to support everything, only DML statements. Thoughts? regards, tom lane
В списке pgsql-hackers по дате отправления: