6 ms·
> don't name them manually let PG name them for you If you care about catching stuff like unique constraint violations in your code then you should know what t
by VWWHFSfQ 2y ago
> don't name them manually let PG name them for you
If you care about catching stuff like unique constraint violations in your code then you should know what the indexes are named.
Always name your indexes and constraints. They're part of your code. How would you catch an exception that you don't know the name of?
- 1a527dd5 2y agoYou don't need to know the name; I prefer to go by the error code PG spits back at you. In this case 23505. https://www.postgresql.org/docs/current/errcodes-appendix.html https://www.postgresql.org/docs/current/errcodes-appendix.ht... That is much more flexible than hard coding the name.
- VWWHFSfQ 2y agoIf you have multiple unique constraints in the same table then it will spit back the same error code. I want to know the name of the specific constraint that was violated. Always name your indexes. Always name your constraints.
- 1a527dd5 2y agoI mean if you have that many violations that points to other problems, but sure if you are in that situation I can see how catching by name might be helpful. It's not a panacea.
- VWWHFSfQ 2y agoIt's not that hard to just name the things you care about instead of relying on auto-generated stuff from the database. PG lets you do this easily. > if you have that many violations that points to other problems No, it doesn't. This is a sophisticated design choice. You might be out of your depth here.
- remram 2y agoAlso useful for migrations, especially if you support multiple DB backends.