Re: Bogus collation version recording in recordMultipleDependencies
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, Julien Rouhaud <rjuju123@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-19T18:49:05Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes: > On Mon, Apr 19, 2021 at 10:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think that the real fundamental bug is supposing that static analysis >> can give 100% correct answers. > Is it really the case that static analysis of the kind that you'd need > to make this 100% robust is fundamentally impossible? I find that > proposition hard to believe. I didn't mean to imply that it's necessarily theoretically impossible, but given our lack of visibility into what a function or operator will do, plus the way that the collation feature was bolted on with minimal system-level redesign, it's sure pretty darn hard. Code like record_eq is doing a lot at runtime that we can't really see from static analysis. Anyway, given the ALTER TYPE ADD ATTRIBUTE counterexample, I'm definitely starting to lean towards "revert and try again in v15". I feel we'd be best off to consider functions/operators that operate on container types to be "maybe"s rather than certainly safe or certainly not safe. I think that such things appear sufficiently rarely in index specifications that it's not worth it to try to do an exact analysis of them, even if we were sure we could get that 100% right. But that doesn't seem to be an idea that can trivially be added to the current design. regards, tom lane
Commits
-
Doc: Update notes about libc collation versions.
- b65431ca5e12 14.0 landed
-
Revert per-index collation version tracking feature.
- ec4831470826 14.0 landed
-
Rethink extraction of collation dependencies.
- f24b15699705 14.0 landed
-
Fix bogus collation-version-recording logic.
- ef387bed87f2 14.0 landed
-
Rename the "point is strictly above/below point" comparison operators.
- 0cc993278888 14.0 cited
-
Move catalog toast table declarations
- b4c9695e79f7 14.0 cited