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

On Mon Jul 6, 2026 at 7:16 PM CEST, Tom Lane wrote:
>> 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.

I found two other edge cases worth considering for this. Which is why I
didn't pursue it further, because I assumed with those two existing
there were probably some more that I missed (and indeed I had missed
that regexes should always be lossy, and there might be more still):

1. bpchar columns should be lossy because LIKE and = behave differently
   for padded values.
2. When the index has a collation, but no collation can be detected for
   the expression, then we currently throw an error during the recheck.
   It seems strange to me to throw that error during execution instead
   of planning, but it seems even weirder that removing the recheck
   would make the query succeed.

Attached a v2 draft patch that adds some tests for those cases and
checks to handle them (and some comments by an LLM that I haven't
cleaned up much). I think issue 2 might need a different approach
altogether. 

To be clear, I don't plan to pursue this further right now, just wanted
to share the details of my investigation in case you want to take it
further.