Tom Lane <tgl@sss.pgh.pa.us> writes:
> Ian Lance Taylor <ian@airs.com> writes:
> > ... most of the cost will be paid by the people who care about
> > it. (Not all of the cost, because some communication will be required
> > when the parse tree nodes are changed.)
>
> > Along these lines, I don't think Bruce's suggestion of modifications
> > to the Postgres gram.y is a good idea, because it causes the Oracle
> > parser to add an ongoing cost to the Postgres parser.
>
> And managing grammar changes and parse-tree-node changes is not an
> ongoing cost? I beg to differ. We do that a lot, and keeping multiple
> grammar files in sync is not a pleasant prospect. (Look at ecpg ---
> it's a major pain to keep it in sync with the main parser, even though
> it only shares productions and not output code. Worse, I have zero
> confidence that it actually *is* in sync.)
Parse tree node changes are definitely an ongoing cost, as I mention
in the first quoted paragraph. However, I would see this as a
communication issue from the people maintaining the core parser to the
people maintaining the Oracle parser. Perhaps it will be possible to
better formalize the parse tree node interface.
(This approach is from my gcc experience. The various gcc parsers (C,
C++, etc.) generate tree nodes. The structure of the tree nodes does
change from time to time, forcing all the other parsers to change.
This is generally driven by the needs of some parser. Different
groups of people maintain each parser.)
I'm not sure what you mean by managing grammar changes, although
perhaps I am reading too much into that. The Oracle grammar is set by
Oracle, and will not change even if the Postgres grammar changes.
> If the grammar changes are small and localized, I think Bruce's #ifdef
> approach might well be the way to go. However, we're speculating in
> a vacuum here, not having seen the details of the changes needed.
I've been trying to avoid the details, because that is just going to
raise another discussion which I honestly believe is orthogonal to
this discussion. However, a quick sketch: proper handling of Oracle
reserved words is very difficult in a Yacc-based parser, because the
set of reserved words effectively changes on a contextual basis. The
Postgres grammar uses various workarounds for this, but doesn't handle
everything entirely correctly from the point of view of the Oracle
language. Therefore, my prototype Oracle grammar is actually a
recursive descent parser, not Yacc-based at all.
Ian
