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