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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
