Re: enhanced error fields

* Peter Geoghegan (peter(at)2ndquadrant(dot)com) wrote:
> > Having just constraint_schema and constraint_name feels horribly wrong
> > as the definition of a constraint also includes a pg_class oid.
>
> I think that it's probably sufficient *for error handling purposes*.
> Since it is non-trivial to get the schema of a constraint, and since
> we have that jarring inconsistency (the schema of the type or the
> schema of the table on which a check constraint is defined?) we might
> well be better off just not addressing it.

I actually really like the idea of being able to programatically figure
out what constraint caused a given error and then go look up that
constraint definition and the comment associated with it, to be able to
pass back a meaningful error to the user. Reducing the cases where
users end up implementing their own application-level error checking
before sending things to the DB is a worthwhile goal, as they often end
up implementing slightly different checking that what the DB does and
get upset when the DB throws an error that they can't do anything useful
with.

> It isn't as simple as you make out. Not all constraints appear within
> pg_constraint (consider NOT NULL constraints), and besides,
> pg_constraint.conrelid can be zero for non-table constraints. What's
> more, pg_constraint actually has three pg_class oid columns; conrelid,
> conindid and confrelid.

Perhaps we can provide a bit more help to our application developers
then by coming up with something which will work consistently- eg: we
provide the data in a structured way to the client and then a function
(or a few of them) which the application can then use to get the
details. I understand that it's complicated and I'd hope that we can do
something better. In general, I wouldn't recommend developers to query
the catalogs directly, but I don't think there's really a better option
currently. If we fix that, great.

In the end, I may agree with you- the patch is a nice idea, but it needs
more to be a complete and working solution and providing something that
only gets people half-way there would result in developers hacking
things together which will quitely break when they least expect it.

Thanks,

Stephen