Re: enhanced error fields

2012/12/29 Stephen Frost <sfrost(at)snowman(dot)net>:
> * 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.

it is a problem of this patch or not consistent constraints implementation ?

Regards

Pavel

>
> Thanks,
>
> Stephen