From: | "Josh Berkus" <josh(at)agliodbs(dot)com> |
---|---|
To: | Kelly McDonald <w4kpm(at)adelphia(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Test to see if currval will fail? |
Date: | 2002-12-06 19:28:44 |
Message-ID: | web-2024461@davinci.ethosmedia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Kelly,
> I have already tried every way that I can think of to catch an
> exception
> by currval, (and learned more since then) and I'm certain that there
> is
> no way to catch an exception, no matter what language you write it
> in.
Unfortunately, you've hit on one of the longstanding TODOs in Postgres
... the lack of nested transactions, which forces all exceptions to be
fatal. For that matter, the isfinite() function is pretty much useless
since it raises an exception if the value passed is not a valid date.
Still, I'm surprise that there isn't a way around fatal exceptions in C
triggers. It seems that you should be able to do this in C.
Bruce is working on nested transactions, and we may even have them for
7.4, 2Q or 3Q 2003. However, there's no good way around your problem
without C hacking right now.
What I personally would love to see in /contrib, as a shortcut, would
be a container C function that returns false if the containerized
function fails, thus:
IF err_container('currval(''some_sq'')') THEN
yugo := currval('some_sq');
END IF;
... but I'm not sure of the praticality of implementing it.
-Josh
From | Date | Subject | |
---|---|---|---|
Next Message | cristi | 2002-12-07 06:05:48 | Check sum function |
Previous Message | Timo Tuomi | 2002-12-06 17:14:26 | Selective sequence.. |