From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Questionable coding in proc.c & lock.c |
Date: | 2000-07-28 15:24:58 |
Message-ID: | 3981A5CA.B56F7740@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | 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
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-07-28 15:33:15 | Re: Inprise InterBase(R) 6.0 Now Free and Open Source |
Previous Message | Denis Perchine | 2000-07-28 15:12:06 | Re: Fwd: Postgres update |