Peter,
* Peter Geoghegan (peter@2ndquadrant.com) wrote:
> Pavel originally included a
> constraint_schema field, because he figured that the way constraints
> are catalogued necessitated such a field.
That's exactly what I was getting at also- in order to do a lookup in
the catalog, you need to know certain information to avoid potentially
getting multiple records back (which would be an error...).
If it isn't possible to uniquely identify a constraint using the
information returned, that's a problem. It's not a question about what
information is necessary- the catalog dictates what the definition of a
constraint is and it includes schema, table, and costraint name. In my
view, we shouldn't be returing a constraint name without returning the
other information to identify that constraint.
How is that different from the schema_name and table_name fields that
you mentioned were going to be included..? Are they not always filled
out for constraint violations and if not, why not? Is there a situation
where we could be getting an error back about a constraint where the
table returned isn't the table which the constraint is on?
If you review the use-case from my last email, I'm hopeful that you'll
see and understand where I think returning this information would be
useful and the information which would be necessary to make that query
work. Even without looking up the comment and instead just trying to
return the source of the constraint which was violated, you need the
information whcih will allow you to uniquely identify the constraint.
Thanks,
Stephen
