Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Дата
Msg-id 3953951.1676991950@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список pgsql-bugs
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> It looks like we need something like the attached, to deal with
> product queries that are INSERT ... SELECT queries. In that case the
> VALUES RTE will be at the same index, but in the SELECT part of the
> product query, not the top-level product query itself.

It seems like this bit:

+                    rtr = (RangeTblRef *) linitial(pt->jointree->fromlist);
+                    selectrte = rt_fetch(rtr->rtindex, pt->rtable);
+                    selectquery = selectrte->subquery;

is missing several essential checks.  Is the node extracted from
jointree->fromlist actually a RangeTblRef?  Seems like it could
be a JoinExpr or FromExpr instead; even if it can't be that today,
an IsA check is cheap future-proofing.  Likewise, once you've
got your hands on the RTE, you should check rtekind == RTE_SUBQUERY
rather than assuming it's safe to touch the subquery field.

(I see that getInsertSelectQuery isn't much better about this,
but we should fix that while we're at it.)

            regards, tom lane



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Unlimited memory consumption with long-lived connection
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Query run in 27s with 15.2 vs 37ms with 14.6