Re: Questionable coding in proc.c & lock.c - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: Questionable coding in proc.c & lock.c
Date
Msg-id 3981A5CA.B56F7740@alumni.caltech.edu
Whole thread Raw
In response to RE: Questionable coding in proc.c & lock.c  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: Questionable coding in proc.c & lock.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Questionable coding in proc.c & lock.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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
restructuring a bit higher up will let us make this a real feature, not
a hack (I hope ;)

btw, even gram.y does touch some of the heap cache (for pg_type) to look
for type existance; don't know if that will be a problem but maybe that
needs to be rethought also...
                  - Thomas


pgsql-hackers by date:

Previous
From: Denis Perchine
Date:
Subject: Re: Fwd: Postgres update
Next
From: Thomas Lockhart
Date:
Subject: Fixed PATH regression test