Sam Mason wrote:
>> Occasionally, though, I do have something where the DB-using app must
>> just submit a request to the DB and see if it works. Either the UI
>> doesn't have the privileges to run the same checks its self, or they're
>> just too expensive to do from the client (or to do twice). In those
>> cases I start to find Pg's error reporting frustrating, and I either
>> resort to a "return value" sort of approach or embed a unique error code
>> and some parseable values in the exception string. Eg:
>>
>> Some kind of human-readable error description goes here
>> [ERR114:ID=12200;CONFLICTING-ID=1111]
>>
>> It's not pretty, but it works.
>>
>
> sounds sensible. Do any other databaes/other tools work better that you
> know of? I keep looking for projects, but this could end up touching
> quite a lot of code.
>
Unfortunately I don't know of anything that already does this sort of
more detailed exception reporting.
Being able to access:
- Individual exception substitution values with their original types or
as text;
- The original exception text with substituted-in values but no
context/location information; and
- A user-specified exception "code" or subtype for PL/PgSQL-thrown
exceptions
would be *so* nice. Even just the last one would make a big difference I
think.
Anybody have any idea how tricky that might be to implement while
maintaining 3.0 protocol compatibility for existing DB interfaces? It
might be a pretty cool GSoC project, though I suspect it might involve a
bit too much of Pg's internals.
Am I the only one who'd want something like that, or does it sound like
something that might be a worthwhile wishlist/distant-todo item?
--
Craig Ringer
