Re: Re: [PATCHES] Select parser at runtime

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Ian Lance Taylor <ian@airs.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2001-08-12T21:22:35Z
Lists: pgsql-hackers
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > Ian Lance Taylor <ian@airs.com> writes:
> > > For example: the datatypes have different names; the set of reserved
> > > words is different; Oracle uses a weird syntax for outer joins.
> > 
> > Is it really possible to fix these things strictly in the parser
> > (ie, without any semantic analysis)?  For example, I don't quite see
> > how you're going to translate Oracle-style outer joins to SQL standard
> > style without figuring out which fields belong to which relations.
> > Keep in mind the cardinal rule for the parsing step: Thou Shalt Not
> > Do Any Database Access (because the parser must work even in
> > transaction-aborted state, else how do we recognize ROLLBACK command?)
> 
> I admit that I haven't sorted out the outer join thing yet.  The
> others are easy enough.
> 

Another idea is to put the Oracle stuff in gram.y, but use #ifdef or
something to mark the Oracle parts, and run gram.y through yacc/bison
with the Oracle defines visiable, and another time to create a second
parse state machine without Oracle.  I think Jan did that for something
like that once.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026