Re: Bogus use of canonicalize_qual
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-03-11T17:23:55Z
Lists: pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On 10 March 2018 at 20:21, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If we suppose that we only need to fix it in HEAD, the most attractive >> answer is to add a parameter distinguishing WHERE and CHECK arguments >> to canonicalize_qual. > I agree that this looks like the best choice, but it feels a little > unsatisfactory to not back-patch a fix for such a glaring bug. You > could perhaps leave the signature of canonicalize_qual() the same, but > add a new canonicalize_check() function, and make both thin wrappers > on top of a local function accepting the is_check parameter. Hm. I'd be inclined to create canonicalize_qual_extended(qual, is_check) and then make canonicalize_qual() call that with is_check = false. But either way would avoid breaking API compatibility for the back branches. I guess the next question is whether we should do it the same way in HEAD, avoiding a cross-branch difference. But I don't like that, because part of the point here IMO is to force any external callers of canonicalize_qual() to reconsider what they're doing. regards, tom lane
Commits
-
Fix improper uses of canonicalize_qual().
- 925581d89cee 9.3.23 landed
- e556fb137279 9.4.18 landed
- e2ed3c4a3002 10.4 landed
- 976e5844ef53 9.6.9 landed
- 4a4e2442a7f7 11.0 landed
- 106d588055a2 9.5.13 landed