Possible feature? - Mailing list pgsql-hackers

From Mike Mascari
Subject Possible feature?
Date
Msg-id 3B4C3676.D8A5C2B5@mascari.com
Whole thread Raw
Responses Re: Possible feature?
List pgsql-hackers
Hello.

I was just curious if you guys would accept a feature which would allow
for the generation of non-standard messages for the violation of index,
check, and referential integrity constraints. I understand that Peter
E's proposal regarding error messages would allow clients to determine
in greater detail the cause of an elog(). However, I think it might be
of value to implement something which would allow the user to override
the default message sent by the backend. An example situation would be
like this:

CREATE TABLE employees (
employeeid integer not null,
ssnumber text not null
);

CREATE UNIQUE INDEX i_employees on employees(ssnumber);

MESSAGE ON INDEX i_employees IS 
'An employee with a matching Social Security number already exists';

Then, when the UNIQUE constraint of the index is violated, instead of
the message:

'Cannot insert a duplicate key into a unique index i_test1'

the client application would receive:

'An employee with a matching Social Security number already exists'

The benefit to a feature like this is that each client application
doesn't need to handle the generation of the appropriate error messages
themselves, but instead can rely on the database to do so. In fact, it
wouldn't be too hard to have a SET command to set the client language
(much like CLIENT_ENCODING) that would return the message appropriate
for the language of the client. 

Another example:

CREATE TABLE cars (
model integer not null,
make integer not null,
color text not null
constraint check_color check (color = 'Red' or color = 'Blue')
);

MESSAGE ON CONSTRAINT check_color IS
'Only Red or Blue cars are valid. Please refer to page 12 of the User''s
Guide';

Of course, its quite probable that all of this belongs in each of the
clients, but it seems trivial to do, much like pg_description and
COMMENT ON. This is obviously an informal suggestion to determine if the
idea should be rejected out-of-hand.

Mike Mascari
mascarm@mascari.com


pgsql-hackers by date:

Previous
From: michael@miknet.net (Michael Samuel)
Date:
Subject: Re: Re: Encrypting pg_shadow passwords
Next
From: Hannu Krosing
Date:
Subject: Re: Any tips for this particular performance problem?