The Pros and Cons of Custom Numeric Types in PostgreSQL

The Pros and Cons of Custom Numeric Types in PostgreSQL

Hey there, fellow data engineers! Have you ever encountered custom numeric types in PostgreSQL? I recently came across a unique implementation where numeric and monetary amounts are stored as a string-typed triplet (value, scale, currency) in the database. While this approach has its benefits, such as faster computations and safer float precision in Python, it can be a pain to work with on the data engineering side.

We have to parse these columns every time we load the data, and it gets even more complicated when internal tools read directly from the database. I’ve read that custom types in PostgreSQL should be avoided whenever possible, but I’m curious to hear your opinions on this.

The main argument for using custom numeric types was that PostgreSQL decimal types aren’t precise enough. However, I’ve had good experiences with Decimal(38,18) in the past. So, should I try to push for a change or learn to live with it?

## The Benefits of Custom Numeric Types
– Faster computations using int operations
– Safer float precision in Python

## The Drawbacks
– Parsing columns can be time-consuming and complex
– Internal tools may require additional processing to read the data

## The Alternative: PostgreSQL Decimal Types
– Decimal(38,18) has proven to be precise enough in the past
– Avoids the need for custom parsing and processing

What’s your take on this? Should I advocate for a change or adapt to the current implementation?

Leave a Comment

Your email address will not be published. Required fields are marked *