On Mon, May 12, 2025 at 11:22:21AM -0700, David G. Johnston wrote:
> On Monday, May 12, 2025, Bruce Momjian wrote:
>
> Yeah, you could name the constraint
> "Custom_error_message_when_the_condition_is_not_met." and then just
> convert underscore to spaces and display that to the user.
On Monday, May 12, 2025, Bruce Momjian wrote:
>
>
> Yeah, you could name the constraint
> "Custom_error_message_when_the_condition_is_not_met." and then just
> convert underscore to spaces and display that to the user.
>
>
The 63 byte limit seems much more likely to be a factor if the name has to
On Sat, May 10, 2025 at 07:58:47PM -0400, Tom Lane wrote:
> "Miguel Ferreira" writes:
> > I propose extending the syntax of the ALTER TABLE ADD CONSTRAINT
> > statement (and potentially CREATE TABLE) to allow for the
> > specification of a custom error message for each CHECK constraint.
>
> Why d
Em sáb., 10 de mai. de 2025 às 21:57, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> Constraints can be targeted by “comment on”.
>
So, why not using that COMMENT ON message to raise when that constraint
gets violated ?
A GUC like Constraint_Exception_Returns_MessageOn = {Never | Alw
De: David G. Johnston
Enviada: 11 de maio de 2025 01:58
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 t
Tom Lane writes:
> Why don't you just choose better names for your constraints?
A word versus a sentence. It's a big difference that greatly improves the
user experience.
> I'd argue that the proposed change might actually be a net loss for
usability, if it entirely obscures the fact that what h
On Saturday, May 10, 2025, Miguel Ferreira
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 con
"Miguel Ferreira" writes:
> I propose extending the syntax of the ALTER TABLE ADD CONSTRAINT
> statement (and potentially CREATE TABLE) to allow for the
> specification of a custom error message for each CHECK constraint.
Why don't you just choose better names for your constraints?
I'd argue tha
PostgreSQL Project Leaders,
Currently, when a CHECK constraint is violated, PostgreSQL returns a generic
error message that includes the constraint name. While informative for
developers familiar with the database schema, this message can be less clear
for other team members, end-users, or i
