Re: Questionable coding in proc.c & lock.c

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

In response to

Responses

Browse pgsql-hackers by date

  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