Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause
От | Bruce Momjian |
---|---|
Тема | Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause |
Дата | |
Msg-id | YwOofIFajASrgRbC@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Sun, Aug 21, 2022 at 01:50:35PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > To improve things, it would be good if we could determine if LATERAL > > will really fix the error, or at least detect one of the cases above we > > have a clearer way to suggest a fix. > > Here's a proposed patch that tries to determine this by looking at > ParseNamespaceItem flags. I'm not sure it's totally bulletproof, > but it's likely good enough for a HINT. Wow, this is great. I can see how people would be confused by the need for LATERAL, and this is really a great boost for them. > I felt that the conditional-expression nests in the existing ereport > calls were nearly unintelligible already, so I rearranged the logic Wow, I am glad you mentioned this. I never saw a ? b ? c : d : e used before and I had to look it up, and I have been around C for a long time: https://www.geeksforgeeks.org/c-nested-ternary-operator/ > to duplicate portions of the ereports instead. That could be debated > perhaps. Also, as written some paths through errorMissingColumn > will invoke the findNSItemForRTE search twice. I'm not too fussed > about that: it's a pretty cheap search and anyway nobody should be > bothering to shave microseconds off an error reporting path. Exactly. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
В списке pgsql-bugs по дате отправления: