Matt Miller <mattm@epx.com> writes:
> If I were fool enough to plan an attack on the main executor's exception
> handling to try and disarm it of its subtransaction semantics, where
> would I start? Where would I end? What would I do in between? Can New
> Orleans be rebuilt above sea level?
In general I don't think it even makes sense to think of making executor
rollback non-transactional. If the executor was running, say, an INSERT
or UPDATE that had already made some database changes before failing,
you certainly don't want those partial results to be seen as good.
ISTM what you are after is to provide some computational capability in
plpgsql that is restricted from doing any database access, and therefore
isn't subject to the above complaint. I'm not sure about a good way to
do this. Seems like your choices are to re-invent the wheel by
implementing a separate expression evaluator inside plpgsql, or to try
to create a locked-down, limited-capability option in execQual.c.
(The main problem with the latter route is to do it without adding any
overhead for normal execution, as otherwise you'll probably get shot
down on that basis.) In either case it's not immediately obvious how
you tell what is safe to allow --- Postgres' model that everything is
embedded within black-box functions doesn't help you here. The
IMMUTABLE/STABLE/VOLATILE marking of functions is close to what you
want, but not close enough.
Also, it might be possible to make the restriction "read-only database
access" instead of "no database access"; this would certainly fit a lot
better with the existing function volatility categories, but then you
still have the problem that aborting the executor is just not a
low-overhead control path. And you would have to go through just about
all of the existing subxact cleanup, such as releasing locks and buffer
pins acquired within the failing query.
regards, tom lane
