On Saturday, May 10, 2025, Miguel Ferreira <miguelmbferre...@gmail.com>
wrote:
> ALTER TABLE table_name
>
> ADD CONSTRAINT constraint_name
>
> CHECK (condition)
>
> MESSAGE 'Custom error message when the condition is not met.';
>
>
I’m seeing some value here but, odds are, there is not enough obvious
benefit or design to convince someone else to try and envision specifically
how the behavior should work and effort to push it through.
>
>
> Improved User Experience: Applications could capture and display more
> contextual and helpful error messages to end-users, improving usability and
> reducing confusion.
>
>
Arguably a layering violation. To make this point more clearly, do you
need to account for i18n?
> Enhanced Debugging: Developers could immediately identify the specific
> business rule that has been violated, speeding up the debugging and
> resolution of data integrity issues.
>
> Is there really a meaningful gap here?
Implicit Documentation: The custom message would serve as a way to
> document the intent of the constraint directly within the database schema,
> facilitating understanding and maintenance of the data model.
>
>
Constraints can be targeted by “comment on”.
> Consistency: It would allow for a more consistent approach to
> providing informative feedback on business rule violations, complementing
> the existing capability in triggers.
>
>
Two different tools that can do the same job. One with structure and one
customizable. Because triggers exist the proposed feature is less useful.
David J.
