Thomas Girault <toma.girault@gmail.com> writes:
> func_expr:
> ...
> | func_arg_expr IS func_name over_clause
> However, my first attempt leads to the following errors :
> /usr/bin/bison -d -o gram.c gram.y
> gram.y: conflicts: 84 shift/reduce, 807 reduce/reduce
> gram.y: expected 0 shift/reduce conflicts
> gram.y: expected 0 reduce/reduce conflicts
Most likely, you need to think about how to distinguish this case from
IS NULL, IS TRUE, and the other things that can follow IS already.
I don't think all those words are considered fully reserved today,
but they'd have to be (or at least not be allowed as func_names)
to make this non-ambiguous. Looking at bison -v output will help
you figure out for sure what it thinks is ambiguous.
> In addition, I would rather making this new functionality independent
> of the original PostgreSQL source code.
> Ideally, the new defined bison rules would be defined in an autonomous
> module extension.
Bison doesn't support that; it needs to see the entire grammar at once.
(Many years ago I worked with systems at HP that did have run-time-
extensible parsers. They were a pain: not all that flexible, and it
was easy to get grammar bugs wherein things parsed some other way than
you expected. To me the main value of bison is that it tells you about
it when you wrote something ambiguous; and for that, it really has to
see all the rules not just some of them.)
> I have seen that some contrib modules (such as SEG or CUBE) define
> separate bison grammar rules.
Those grammars have nothing to do with parsing SQL; they're just used to
parse literal values of those data types.
> Can I define my new bison rules separately of the gram.y file?
> Can I use the new functionality dynamically after loading an extension
> module (LOAD 'MY_EXTENSION';)?
No, and no.
regards, tom lane
