Improve ClickHouse data type mapping documentation

[tlblessing]

Description

Add table for reverse mapping direction. Clean up table formatting.

Is this change a fix, improvement, new feature, refactoring, or other?

Improvement

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

Connector documentation

How would you describe this change to a non-technical end user or system administrator?

Added a table of the data types from Trino back to ClickHouse. Reformatted table for better wrapping and consistency.

Documentation

( ) No documentation is needed.
(x) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

[ebyhr]

There's an existing PR #13259. Could you coordinate with @tangjiangling ?

[tlblessing]

There's an existing PR #13259. Could you coordinate with @tangjiangling ?

Sure, I could apply your review comments to my PR. Is that okay with you @tangjiangling ?

cc: @jhlodin

[tangjiangling]

Is that okay with you @tangjiangling ?

Sure.

[ebyhr]

I would recommend improving the commit titles to clarify this is document change. It helps us when reading commit history.

• Add header for ClickHouse type mapping documentation
• Document write mapping and reformat table in ClickHouse
• Fix typo in ClickHouse documentation

[colebow]

You're going to need to squash these later commits down into the proper original commits. Trino has a strict policy on commits being atomic, sensible units of change. Code review shouldn't result in extra commits unless the review has prompted you to make a new, independent change which deserves to be separated from the prior work. Trino is similarly strict with commit messages, and we try to follow this guide: https://cbea.ms/git-commit/

When you get feedback or suggestions, you should amend your edits into the commit where you made the change.

My workflow for this is usually:

Make my changes, stage my changes
git log --oneline -3 (or whatever number you need)
Copy the hash of the commit I'm editing
git commit --fixup <hash>
git rebase -i HEAD~3 --autosquash

And that should get all changes into the original commit as appropriate. There's several different ways to accomplish the same thing in Git, but that strategy works best for me.

If you've already made the edit commit like you have here, you can do a rebase, re-order the unnecessary commits to follow the ones they're editing, and change them from pick to fixup to merge them into the proper commits. Rebasing is also the easiest way to rename those original commits.

[mosabua]

@tlblessing and @colebow please work on the git-fu together as necessary.

[tlblessing]

@tlblessing and @colebow please work on the git-fu together as necessary.

Will do. Cole is OOO until mid next week.

[tlblessing]

I assume that these types should also be all uppercase @ebyhr ? Except for Float64 etc. ?

[ebyhr]

Merged, thanks!