Using postgresql, how to prevent new inserts on varchar column using ^@ / starts_with operator / function?
1
vote
1
answer
471
views
I'm trying to create a table with a
path
column. This table should only allow inserting a new path if the new path is neither an ancestor nor a descendant of any already inserted path. i.e. with '/foo/bar'
already in the table:
- inserting '/foo/bar'
should fail
- inserting '/foo/bar/baz'
should fail
- inserting '/foo/bar/baz/bat'
should fail
- inserting '/foo'
should fail
- inserting '/'
should fail
- inserting '/foo/bar2'
should succeed
- inserting '/foo/baz'
should succeed
- inserting '/fox/bar'
should succeed
- inserting '/xxx/yyy/foo/bar'
should succeed
Essentially, these are absolute and fully-resolved (no /../
or /./
) unix path to some filesystem directories (they are relative in my precise use case but all will have the same origin so they can be safely compared with the same logic as one would use for absolute paths).
My solution was to try an exclude constraint
using the ^@
(aka starts_with
) operator (with proper r-trimming and appending of a path delimiter to avoid false-positives, like /foo/bar
and /foo/bar2
.
with
CREATE TABLE location (
id UUID NOT NULL,
path VARCHAR NOT NULL,
EXCLUDE USING btree ((rtrim(path, '/') || '/') WITH ^@)
)
which gets me this error:
Only commutative operators can be used in exclusion constraints.
I know the operator is not commutative, but I (wrongly) expected postgres would see this and do the check both ways (thus excluding both ancestors and descendants).
I've tried looking up alternatives but haven't found one. **How can I enforce this constraint at the db level?** I really don't want to do this at the application level, as this would force me to deal with race conditions for something that really should be dealt with on the db side (data integrity concerns).
The only other solution I can see is using an insert trigger that select all the rows in the table and throws if any of them matches my condition. This seems inefficient, and a bit ugly (it would essentially be a PL/pgSQL version of that exclude constraint, thus foregoing any performance benefit of an index).
Any ideas ? Thanks in advance :)
Asked by takeshi2010
(21 rep)
Nov 9, 2021, 05:19 PM
Last activity: Feb 9, 2025, 06:07 PM
Last activity: Feb 9, 2025, 06:07 PM