Re: Select parser at runtime

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> > I've been experimenting with using a different parser (one which is
> > more Oracle compatible).
>
> Hmm.  What we have here is a mechanism to swap out the entire
> backend/parser/ subdirectory --- and nothing else.  Somehow this seems
> like the wrong granularity.  parser/ is an awful lot of code to replace
> to make a few random tweaks that don't affect query semantics.  Since
> you aren't changing the querytree representation nor any of the rewrite/
> plan/execute pipeline, it's hard to see how you can do more with this
> than very marginal syntax hacks.  But if that's all you want to do,
> seems like replacing pieces of the parser/semantic analyzer is the right
> mechanism, not the whole durn thing.

This patch doesn't actually replace the entire backend/parser
subdirectory.  It mainly only replaces scan.l and gram.y.  This is
because the code in postgres.c still passes the result of the replaced
parser to pg_analyze_and_rewrite().

You are absolutely correct that at this point this can only do
marginal syntax hacks.  But since my goal is to support Oracle syntax,
marginal syntax hacks are just what is needed.  For example, it's hard
to tweak the existing parser to support Oracle, because the set of
reserved words is different, and because Oracle uses different names
for datatypes.  Also, CREATE FUNCTION in Oracle doesn't use a literal
string, it actually switches to a different parser while parsing the
function.  It's not impossible to hack these into the Postgres parser;
just hard, and a complex maintenance problem.

It's true that increased Oracle compatibility will require code
changes in other parts of the backend.

> > Note that you may want to leave yourself an escape
> > hatch of some sort to set the parser back to Postgres standard.
> > If this patch is accepted, then some further work needs to be done to
> > set the parser for SPI calls, so that it is possible for the user to
> > change the parser while still using ordinary PL/pgSQL.
>
> I think both of these issues would need to be addressed before, not
> after, considering the patch for acceptance.  In particular, how do we
> cater for both plpgsql and a true "PL/SQL" language that uses the Oracle
> parser?

I agree that these issues need to be addressed before the patch is
accepted.  I want to get a sense of whether I am on the right track at
all.

As noted above, PL/SQL needs to be more closely tied to the Oracle
parser than PL/pgSQL is to the Postgres parser.

I have been thinking in terms of a parser stack.  Code which uses SPI
could push the correct parser on top of the stack, and pop it off when
done.  Perhaps SPI would always use the postgres parser unless
explicitly directed otherwise.  The PL/SQL language interface would
direct otherwise.

Thanks for your other comments.  I went with a dynamic link approach
because it seemed minimally intrusive.  Using a straight function
pointer is certainly easier.

Ian