Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Normalize `Numeric` (No scale or precision) Values

Open
  • Is something wrong?
#406 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, postgresql
Domain
databases

Research direction

Start in the pg-clickhouse-c code that reads tuples: pgch__read_tuple() and pgch_read_value(), down to pgch__read_decimal(), and compare the regression outputs in test/expected/aggregates.out and aggregates_2.out. Done means a precision-free NUMERIC result drops trailing zeros the way Postgres does, via numeric_normalize, while the Decimal(76, 38) path and its precision stay unchanged. Check the tests still pass for both expected files.

Written by the indexing model from the issue text.

Description

bug data types pushdown

#396 demonstrates how round(numeric) when pushed down returns the full 38 decimal places of precision with trailing zeros, while when run in Postgres it omits the trailing zeros:

Compare the output of round(regr_syy(b, a)::numeric, 4) in test/expected/aggregates.out, where it pushes down:

68756.21570000000000000000000000000000000000

To test/expected/aggregates_2.out, where it does not:

68756.2157

It remains accurate of course, but somewhat unexpected relative to Postgres. This happens because Postgres numeric has a display scale but we don't set it. IOW, we see all the zeros because we've mapped numeric to Decimal(76, 38) and pg-clickhouse-c thus decides it's NUMERIC(76, 38).

We need a way to normalize such values without actually losing precision. Thus, when pg_clickhouse handles NUMERIC without scale or precision, we need to convert the value returned from ClickHouse to the normalized value.

Perhaps we should apply numeric_normalize?

This should happen only for precision-free NUMERIC. We have to track that we've told ClickHouse that it's Decimal(76, 38) and treat it as numeric when the output type has no precision.

My guess? We need to pass the target Postgres data type (OID and typdef; neither seems to be there now --- add to chc_type?) to pgch_read_value() (and from there to pgch__read_decimal()) in pgch__read_tuple() in pg-clickhouse-c. Then have pgch__read_decimal() apply numeric_normalize when the datum has no precision.

Dominant language
C
Stars
294
Forks
23
Avg merge
1d 2h
Merged PRs (30d)
37

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ClickHouse/pg_clickhouse

All issues in ClickHouse/pg_clickhouse

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.