opt: fix BPCHAR type and CASE typing

[mgartner]

This commit addresses inconsistencies from Postgres' behavior. First, it
makes the BPCHAR type distinct from CHAR. The former is a
blank-padded character type with no type width, meaning that it could
have any length. The latter is a blank-padded character type with a type
width of exactly 1 - it is essentially an alias of CHAR(1).
Previously, a column of type BPCHAR behaved the same as a column of
type CHAR(1) - it enforced a length limit of 1.

Second, the typing of CASE and CASE-like expressions has been fixed.
The branches of these conditionals is no longer forced to have the same
type-width.

Fixes #127889
Fixes #108360

Release note (bug fix): A bug has been fixed that caused incorrect
evaluation of CASE, COALESCE, and IF expressions with branches
producing fixed-width string-like types, such as CHAR. In addition,
the BPCHAR type has been fixed so that it no longer incorrectly
imposes a length limit of 1.

[cockroach-teamcity]

This change is 

[DrewKimball]

Thanks for the fix! Assuming the test cases check out,

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)

---

pkg/sql/logictest/testdata/logic_test/case line 71 at r1 (raw file):

ba

subtest end

I'd be curious to see a few additional tests:

SELECT CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::CHAR;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::BPCHAR;

In Postgres:

postgres=# SELECT CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::CHAR;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::BPCHAR;
 case
------
 foo
(1 row)

 bpchar
--------
 f
(1 row)

 bpchar
--------
 foo
(1 row)

[mgartner]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @DrewKimball)

---

pkg/sql/logictest/testdata/logic_test/case line 71 at r1 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

I'd be curious to see a few additional tests:

SELECT CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::CHAR;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::BPCHAR;

In Postgres:

postgres=# SELECT CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::CHAR;
SELECT (CASE WHEN false THEN 'b'::CHAR ELSE 'foo'::TEXT END)::BPCHAR;
 case
------
 foo
(1 row)

 bpchar
--------
 f
(1 row)

 bpchar
--------
 foo
(1 row)

Done.

[mgartner]

I realized this is related to #108360. I'll have a follow-up PR to address a few more things I found (mentioned in that issue).

[mgartner]

I actually need to do the follow-up work in this same PR to get the tests to pass. We need to represent a CHAR(N) type with no type width in SQL when we serialize the cast for distributing it to other nodes. Because we simply serialize it as CHAR now, the remote node parses it as CHAR(1) semantically. This causes the typing logic tests to fail under fakedist and other configurations.

[mgartner]

I had to adjust some of the UDF resolution logic to find overloads with CHAR, CHAR(N), or BPCHAR parameters with any three of those variations. The behavior now matches Postgres more closely.

[mgartner]

@DrewKimball mind taking one more quick look?

[mgartner]

Friendly ping @DrewKimball. :)

[DrewKimball]

Reviewed 1 of 2 files at r2, 10 of 22 files at r3, 16 of 16 files at r4, 2 of 2 files at r5, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @mgartner)

[mgartner]

TFTR!

bors r+

[craig]

Build succeeded:

• windows_build
• acceptance
• examples_orms
• linux_amd64_fips_build
• local_roachtest
• linux_arm64_build
• lint
• check_generated_code
• macos_arm64_build
• local_roachtest_fips
• macos_amd64_build
• linux_amd64_build
• docker_image_amd64
• unit_tests

[blathers-crl]

Based on the specified backports for this PR, I applied new labels to the following linked issue(s). Please adjust the labels as needed to match the branches actually affected by the issue(s), including adding any known older branches.

---

Issue #127889: branch-release-23.1.

---

Issue #108360: branch-release-23.1, branch-release-23.2, branch-release-24.1, branch-release-24.2.

---

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[blathers-crl]

Encountered an error creating backports. Some common things that can go wrong:

1. The backport branch might have already existed.
2. There was a merge conflict.
3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.

---

error creating merge commit from 4a11c7d to blathers/backport-release-23.1-129007: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.x failed. See errors above.

---

error creating merge commit from 4a11c7d to blathers/backport-release-23.2-129007: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.2.x failed. See errors above.

---

error creating merge commit from 4a11c7d to blathers/backport-release-24.1-129007: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 24.1.x failed. See errors above.

---

error creating merge commit from 4a11c7d to blathers/backport-release-24.2-129007: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 24.2.x failed. See errors above.

---

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}