From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "lxndrkrlv(at)gmail(dot)com" <lxndrkrlv(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause |
Date: | 2022-08-21 17:50:35 |
Message-ID: | 4158934.1661104235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)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.
I felt that the conditional-expression nests in the existing ereport
calls were nearly unintelligible already, so I rearranged the logic
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
improve-missing-column-error-hints-1.patch | text/x-diff | 18.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2022-08-21 19:07:28 | Re: BUG #17543: CSVLOG malformed from disk space error |
Previous Message | Etsuro Fujita | 2022-08-21 12:31:35 | Re: foreign join error "variable not found in subplan target list" |