4 ms·

All this does is make writing a CHECK constraint for a JSON blob relatively straightforward. And yes you should use CHECKs in the database. In practice, it is v

All this does is make writing a CHECK constraint for a JSON blob relatively straightforward. And yes you should use CHECKs in the database. In practice, it is very easy for application code to either not check or screw it up. It is much harder to find and clean up bad data in the database than prevent it from being inserted. By making it a schema config, it is much easier to audit by other engineers and more likely to be correct. If CHECKs are causing perf issues, then okay maybe put the problematic ones somewhere else.

westurner 4y ago
You could cost the stored procedures' deployment costs in cryptographically-signed-redundant-data-storage bytes and penalize unnecessary complexity by Costing Opcodes (in the postgres database ~"virtual machine runtime", which supports many non-halting programming languages; such as rust, which is great to see.) and paying for redundant (smart contract output) consensus where it's worth it. TIL about https://github.com/mulesoft-labs/json-ld-schema https://github.com/mulesoft-labs/json-ld-schema: "JSON Schema/SHACL based validation of JSON-LD documents". Perhaps we could see if that's something that should be done in pgx or in the application versions deployed alongside the database versions?