Gregory Stark <[EMAIL PROTECTED]> writes:
> Well one thing that might be useful for a c++ procedural language would be
> catching C++ exceptions and translating them into ereports which could then be
> caught in Postgres.
> That's actually what I thought you had done but I just reread your mail and
> realized you only handled unhandled exceptions which cause the backend to die.
Well, that's too bad, because fixing the error-handling impedance
mismatch is the one thing that's been missing from every previous
proposal, and it's the one thing that might actually make C++ in the
backend useful rather than a toy.
It's possible/likely that this would be easier to do in the context of
a PL; that would at least provide a single point at which to catch
C++ exceptions and turn them into elogs. The hard part is turning
elogs into exceptions so that errors thrown by core backend functions
that're called by the C++ code will behave as a C++ programmer would
expect.
For comparison look at the way that errors are handled in pl/perl etc.
The relatively narrow "SPI" API for calling back into the main backend
makes it somewhat sane to convert elogs into Perl errors, though it's
less efficient than one could wish. I don't know how to scale that
solution up to the point where you could call any random internal
backend function, as Kurt seems to be hoping for.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
