harmonize h3PointDist* error messages

[yohannj]

When error msg in getReturnTypeImpl would print

Illegal type Int8 of argument 0 of function h3PointDistM. Must be Float64

Error msg in executeImpl would print

Illegal type Int8 of argument 1 of function h3PointDistM. Must be Float64

This PR ensures both messages are the same, and choose to follow the error message in executeImpl.

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

...

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

Modify your CI run

NOTE: If your merge the PR with modified CI you MUST KNOW what you are doing
NOTE: Checked options will be applied if set before CI RunConfig/PrepareRunConfig step

Include tests (required builds will be added automatically):

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• All with ASAN
• All with TSAN
• All with Analyzer
• All with Azure
• Add your option here

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• Add your option here

Extra options:

• do not test (only style check)
• disable merge-commit (no merge from master before tests)
• disable CI cache (job reuse)

Only specified batches in multi-batch jobs:

• 1
• 2
• 3
• 4

[robot-clickhouse-ci-2]

This is an automated comment for commit 524f289 with description of existing statuses. It's updated for the latest CI running

❌ Click here to open a full report in a separate page

Check name	Description	Status
CI running	A meta-check that indicates the running CI. Normally, it's in success or pending state. The failed status indicates some problems with the PR	⏳ pending
ClickHouse build check	Builds ClickHouse in various configurations for use in further steps. You have to fix the builds that fail. Build logs often has enough information to fix the error, but you might have to reproduce the failure locally. The cmake options can be found in the build log, grepping for cmake. Use these options and follow the general build process	❌ failure
Mergeable Check	Checks if all other necessary checks are successful	❌ failure

Successful checks

Check name	Description	Status
A Sync	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Docs check	Builds and tests the documentation	✅ success
Fast test	Normally this is the first check that is ran for a PR. It builds ClickHouse and runs most of stateless functional tests, omitting some. If it fails, further checks are not started until it is fixed. Look at the report to see which tests fail, then reproduce the failure locally as described here	✅ success
PR Check	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Style check	Runs a set of checks to keep the code style clean. If some of tests failed, see the related log from the report	✅ success

[rschu1ze]

We could use FunctionArgumentDescriptor (src/Functions/FunctionHelpers.cpp) which does all the validation based on an descriptor struct. This would also guarantee consistent error messages (across all functions using FunctionArgumentDescriptor).

[yohannj]

That would indeed be a lot better!

Looks like validateArgumentType is currently used in in geohash functions, and I don't see any usage of validateArgumentsImpl.
From what I previously saw in the codebase, that could be applied for most functions (there are exceptions like hascolumnintable or some functions that accepts 1 or 3 parameters).
So I suppose either it's done from time to time (like in this PR), or a single PR updates the different functions.

I never learnt how to code in cpp, so when contributing to the codebase, I'd rather stay in fixing typo and other minor things.
I don't feel comfortable introducing that change in this PR myself.