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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Date: 2023-02-21 18:02:38
Message-ID: 3977948.1677002558@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> Yeah, that makes sense. Something like this? (I think an elog() is
> probably more useful than an Assert(), if we don't find what we
> expect.)

I think it's fine to leave the checks on parsetree->jointree being
a FromExpr as Asserts, because that's assumed in a lot of places.
Rest of it is OK by me.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Janes 2023-02-21 19:08:59 Re: Query run in 27s with 15.2 vs 37ms with 14.6
Previous Message Tom Lane 2023-02-21 17:27:54 Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash