
> > > I think maybe what needs to be done to fix all this is to 
> restructure
> > > postgres.c's interface to the parser/rewriter.  What we want is to
> > > run just the yacc grammar initially to produce a list of raw parse
> > > trees (which is enough to detect begin/commit/rollback, no?)  Then
> > > postgres.c walks down that list, and for each element, if it is
> > > commit/rollback OR we are not in abort state, do parse analysis,
> > > rewrite, planning, and execution.  (Thomas, any comments here?)
> > 
> > Sure, why not (restructure postgres.c that is)? I was just thinking
> > about how to implement "autocommit" and was considering 
> doing a hack in
> > analyze.c which just plops a "BEGIN" in front of the 
> existing query. But
> 
> Man, that is something I would do.  :-)

Wouldn't the hack be to issue a begin work after connect,
and then issue begin work after each commit or rollback ?

Andreas

Mon, 7 Aug 2000 15:23:11 +0200 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Questionable coding in proc.c & lock.c
> > > ... was considering doing a hack in
> > > analyze.c which just plops a "BEGIN" in front of the
> > existing query.
> Wouldn't the hack be to issue a begin work after connect,
> and then issue begin work after each commit or rollback ?

Sure. When hacking all things are possible ;)

But I do have some preference for not doing work until something is
requested (not me personally, but in the code) so would prefer to issue
the BEGIN at the first query.

                     - Thomas

Mon, 07 Aug 2000 15:03:24 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: AW: Questionable coding in proc.c & lock.c