| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | AW: Questionable coding in proc.c & lock.c |
| Date: | 2000-08-07 13:23:11 |
| Message-ID: | 11C1E6749A55D411A9670001FA687963368040@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zeugswetter Andreas SB | 2000-08-07 13:32:45 | AW: pg_dump & performance degradation |
| Previous Message | Romanenko Mikhail | 2000-08-07 11:04:27 | Trouble with float4 after upgrading from 6.5.3 to 7.0.2 |