Re: Noob Hints on testing and debugging?

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