3 ms·
I used to recommend `CHECK` constraints as well, but was directed towards Postgres' very good intelligence around being able to relax a `VARCHAR(n)` -> `VARCHAR
by brandur 5y ago
I used to recommend `CHECK` constraints as well, but was directed towards Postgres' very good intelligence around being able to relax a `VARCHAR(n)` -> `VARCHAR(>n)` as basically a no-op, so I simplified here somewhat just because VARCHARs are easier to use, and make much more succinct examples in write ups like this one.
The index rebuild is still a bit of an open question — I wouldn't be surprised if Postgres had some optimizations there as well to not need it in instances where it's not necessary, but I might be wrong on that one.
- masklinn 5y ago> I used to recommend `CHECK` constraints as well, but was directed towards Postgres' very good intelligence around being able to relax a `VARCHAR(n)` -> `VARCHAR(>n)` as basically a no-op I don’t think that’s the case when you have views on the table though. The locking could also be a concern, altering the table will almost certainly need an exclusive write lock, altering a contraint may not (to check). Even if the operation is very short, the need to block every read coming after the DDL can be quite impactful to service.
- masklinn 5y agoCan't edit anymore but after checking up on https://www.postgresql.org/docs/current/sql-altertable.html https://www.postgresql.org/docs/current/sql-altertable.html only `FOREIGN KEY` constraints can get by with a lock below ACCESS EXCLUSIVE. So constraint or column makes no difference to the locking, sadly.