From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, "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-11-04 19:07:02 |
Message-ID: | 2475055.1667588822@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I did wonder why errorMissingColumn doesn't consider rte_visible_if_* in
> the case when there *is* an rsecond candidate. I understand that the
> reason is that if we come across any exact match we already return that
> one without looking for a second one. Maybe this deserves a comment (in
> errorMissingColumn I mean) but I also wonder if we shouldn't scan the
> whole RT in case there's another exact match that's also not visible.
Um. I'd not wanted to touch the fuzzy-search stuff because it seemed
like a mess of incomprehensible (if not actually buggy) code. But you
have a point --- I'd already noticed that the code was encouraging
people to qualify with a name that might be the wrong table altogether.
So here's a revision that tries to clean that up a little. 0001 is the
same patch as before, and then 0002 revises the fuzzy-search logic enough
that I can make sense of it. I split them mainly so that you can see the
behavioral difference in the changed test outputs.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v2-0001-improve-missing-column-error-hints.patch | text/x-diff | 18.4 KB |
v2-0002-improve-fuzzy-matching-logic.patch | text/x-diff | 15.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-11-05 17:07:44 | Re: BUG #17618: unnecessary filter column <> text even after adding index |
Previous Message | PG Bug reporting form | 2022-11-04 17:15:32 | BUG #17678: Script exit code: 1332 |