Re: Make \d tablename fast again, regression introduced by 85b7efa1cdd

"Jelte Fennema-Nio" <postgres@jeltef.nl> writes:
> On Sat, 4 Jul 2026 at 22:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I looked this over, and I think it's basically right, but don't
>> we need to check that *both* of the collations are deterministic?

> That's not what the code did before 85b7efa1c at least. And I think that's 
> correct because I think it's fine if the index collation is 
> nondeterministic: it'll return a superset of the matches that the 
> expression collation thinks are equal, and then the recheck condition will 
> filter out the conflicting cases (because it's marked as lossy).

Hmm.  Okay, but the comment had better make it explicit that we're
relying on that superset assumption.

> Attached is v3, which adds a test for this case and expands the comment.

I fooled with the comments and test cases some more and pushed it.
(I don't like test cases that create one-off tables, especially not
when there are existing tables that will serve the purpose just as
well.  The regression tests are slow enough already.)

> P.S. I think we could mark the comparisons in certain cases as
> non-lossy, but after trying that for a bit the details turn out more
> complicated than I expected. And that's definitely not something to backport.

Yeah, that was my immediate reaction to your message.  I agree it's
only material for HEAD, but here's a draft patch to do that.

			regards, tom lane