Remove unary operator inverses

[frankmcsherry]

A better version of #27109

Motivation

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[ggevay]

So, could_error would need to be also added to the if? Unfortunately, that will exclude around 95+% of cases, but maybe not all cases, so we could still merge this with could_error. (Maybe future improvements to make could_error more precise will also help.)

But before merging, we need to fix some inverse annotations. This PR revealed that the inverse annotations on bytea_to_text and text_to_bytea are wrong, because bytea_to_text gives gibberish instead of actual text. E.g., the following slt is failing with this PR, because we get back the "hello" due to removing both casts:

query T
SELECT 'hello'::bytea::text
----
\x68656c6c6f

(I've checked that this output is consistent with Postgres.)
@frankmcsherry, could you please change these inverse annotations to #[inverse = None].

[ggevay]

Btw. I'm planning to extend test_smoketest_all_builtins to check the inverse annotation, which would have revealed this bug.

[frankmcsherry]

Well, this being green means it isn't doing anything on our test slts. I think there is at least one prod workload that would technically benefit from this, though no ideas if it unlocks any news plans.

[ggevay]

@mgree could probably tell you how much this situation (or the generalized version, with other casts) occurs in customer plans.

[mgree]

So, could_error would need to be also added to the if? Unfortunately, that will exclude around 95+% of cases, but maybe not all cases, so we could still merge this with could_error. (Maybe future improvements to make could_error more precise will also help.)

I'm less certain about how bad the impact would be---if the could_error is on the outer function, we should be able to eliminate the cast. The idea is that erroring casts are left-inverses: text_to_varchar[k](varchar_to_text[k](s) == s for all s :: varchar(k), because we started from something known to be good. I discuss this a bit in the design doc.

@mgree could probably tell you how much this situation (or the generalized version, with other casts) occurs in customer plans.

Would you like me to run this analysis? Would probably only take a few minutes this afternoon.

[ggevay]

if the could_error is on the outer function, we should be able to eliminate the cast.

Hmm, interesting! Responded there.

Would you like me to run this analysis? Would probably only take a few minutes this afternoon.

That would be great, thank you! It's hard for me to judge at the moment how often this might occur in customer plans, so it would be great to have actual data on this.

[mgree]

That would be great, thank you! It's hard for me to judge at the moment how often this might occur in customer plans, so it would be great to have actual data on this.

I ended up getting side-tracked with Frank today; I can take a look at this next time I'm online.