Re: Another multi-row VALUES bug

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Another multi-row VALUES bug
Дата
Msg-id 641849.1669661559@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Another multi-row VALUES bug  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> A different way to do this, without relying on the contents of the
> targetlist, is to note that, while processing a product query, what we
> really want to do is ignore any VALUES RTEs from the original query,
> since they will have already been processed. There should then never
> be more than one VALUES RTE left to process -- the one from the rule
> action.

> This can be done by exploiting the fact that in product queries, the
> rtable always consists of the rtable from the original query followed
> by the rtable from the rule action, so we just need to ignore the
> right number of RTEs at the start of the rtable. Of course that would
> break if we ever changed the way rewriteRuleAction() worked, but at
> least it only depends on that one other place in the code, which has
> been stable for a long time, so the risk of future breakage seems
> managable.

This looks like a good solution.  I didn't actually test the patch,
but it passes an eyeball check.  I like the fact that we can verify
that we find only one candidate VALUES RTE.

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Failed Assert in pgstat_assoc_relation
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: predefined role(s) for VACUUM and ANALYZE