Re: dunction issue

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