On Mon, 2026-03-23 at 13:02 +0000, Mauricio Martini wrote:
> I am evaluating an approach to change the scale of a numeric column from numeric(18,2)
> to numeric(18,4) in a large table, aiming to avoid the cost of a full table rewrite.
>
> The proposed approach involves directly updating the PostgreSQL system catalog:
>
> UPDATE pg_attribute SET atttypmod = (18 << 16 | 4) + 4 WHERE attrelid = 'table'::regclass
> AND attname = 'column';
>
> Before considering this in practice, I would like to validate a few points:
> * Is this approach considered safe from a data integrity perspective?
> * Is there a risk of inconsistencies in the internal representation of the numeric
> type (especially regarding scale)?
> * Could this impact indexes, functions, or aggregation operations?
> * Is there any official recommendation or prior experience using this approach in
> production environments?
> * Are there additional risks related to rollback, maintenance, or future operations
> (e.g., dump/restore, upgrades)?
>
> The goal is to determine whether this alternative is viable, or if we should stick with more
> standard approaches (e.g., shadow column, incremental migration, etc.).
> If anyone has experience with a similar scenario, your insights would be appreciated.
It should be safe to perform this catalog modification, but I won't take any
liability. "If it breaks, you get to keep both pieces."
Two things come to my mind when considering such a dangerous activity:
- LOCK the table in ACCESS EXCLUSIVE node while you perform the operation
- make sure there is no view that depends on the column, or if there is,
drop the view first and re-create it afterwards
I myself would be a tad afraid to perform something like that. Test well.
Yours,
Laurenz Albe
