Tom Lane wrote:
(eg how to run it up and feed it SQL ideally without running a
postmaster and execing a back end)
Why would you consider that "ideal"? Such a scenario would have
approximately zip to do with the real-world environment your patch
would face.
Your points what? If I'm fiddling with the language parser and
transaction engine, that's
hardly relevant. Its necessary to debug in a full env too, of course,
but an ability
to run a standalone engine which does its own private shmem setup would be
handy. If its not there, too bad.
It makes the compile/test cycle much faster, since you don't have to
go through the rigmarole of attaching to a process, and its one of the
aspects of
using VS that's a whole pile nicer than the make/start/gdb-to-process
stuff I have to
use at work. (And at least I have TotalView there, even if the admins can't
organise KDevelop or Anjuta or Eclipse.)
Is there any sanity at all in a trigger-on-rollback? Exactly what would
you expect it to be able to accomplish that anyone else could see after
the transaction has rolled back? (And no, trigger on commit isn't very
much saner.)
Why do you say this? I'm interested in side effects external to the
db. Logging to a custom
logger is an obvious trivial example - in fact I want to set flags in
the data triggers and then
process them. I'm currently thinking that rollback can be dispensed
with in favour of a setup
phase on commit start.
I'm looking to do things that would otherwise be handled with the event
system for some
use cases but not all (eg a final consistency check point in before
commit). Since that
seems to have issues and this can be more general, it seems worth
looking at.
I'll post a straw man.
James
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
