|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|