Skip to content

Conversation

@Lukasdoe
Copy link
Contributor

The documentation on numeric precision is now adjusted to the current behavior of cedardb and better highlights differences to postgres numerics.

| `numeric(18, 0)` | -999999999999999999 | 999999999999999999 | 8 Byte |
| `numeric(18, 3)` | -999999999999999.999 | 999999999999999.999 | 8 Byte |
| `numeric(38, 0)` | -99999999999999999999999999999999999999 | 99999999999999999999999999999999999999 | 16 Byte |
| `numeric(38, 6)` | -99999999999999999999999999999999.999999 | 99999999999999999999999999999999.999999 | 16 Byte |
Copy link
Contributor

@ElenaKrippner ElenaKrippner Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Cedar, inserting bigger/smaller values is possible, see cedardb/cedardb#2619 , but I agree that this range is what we would want to do.
@bandle should we update the documentation now or make sure that we always check the numeric precision?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, and I'm a bit concerned that this is tricky to fix properly without touching the definition of precision. Consider this query:

SELECT 99999999999999999999999999999999999999::numeric(38, 0) + 1 - 1;

Restricting numerics to the entered precision would (probably) require checks after every arithmetic operation..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants