arkhipov.nr@gmail.com writes:
> I noticed that the error response for a constraint violation only contains the column name for not-null constraints.
I'mconfused because the field isn't present when other types of constraints are triggered, such as unique, foreign
keys,and check constraints. Was this done intentionally because these other constraints may involve multiple columns,
whilethe column_name field expects a single column?
> I understand that a client can find out which columns are involved by a constraint name. Alternatively, should it be
mademore handy so that the column_name field is present for all constraints and includes all involved columns?
This does not sound like a great idea to me. Our manual clearly
defines the contents of the column_name field as a single name:
If the error was associated with a specific table column, the
name of the column. (When this field is present, the schema
and table name fields identify the table.)
To cram more names in there, we'd have to institute some kind of
quoting convention, which would break all existing clients that
are doing anything nontrivial with the field. Unique indexes on
expressions would present even more challenges.
Also, the point of reporting the constraint name for unique and FK
errors is that that name is unique (among the constraints or indexes
of a particular table, anyway). No such assumption could be made
for the set of columns in an index or FK.
regards, tom lane
