[HACKERS] Module extension for parsing and rewriting functions with infixed syntax
Hello, I am working on a PostgreSQL extension module which defines new grammar rules completing the classical SQL syntax defined in the src/backend/parser/gram.y file. Basically, I want to handle predicates having an infixed syntax { X IS Y } and rewrite them as classical Boolean functions with prefixed syntax { Y(X) }. For instance, the following query : SELECT * FROM cars WHERE cars.color IS yellow; would be rewritten into : SELECT * FROM cars WHERE yellow(cars.color); The new predicate could be rewritten as a plpgsql Boolean function with an unique argument (cars.color IS yellow --> yellow(cars.color)). I have then added the following rule to the "func_expr" definition (see gram.y:10280 in postgresql-9.1beta3 source code) : func_expr: ... | func_arg_expr IS func_name over_clause { FuncCall *n = makeNode(FuncCall); n->funcname = $3; n->args = list_make1($1); n->agg_order = NIL; n->agg_star = FALSE; n->agg_distinct = FALSE; n->func_variadic = FALSE; n->over = $4; n->location = @1; $$ = (Node *)n; } ... 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 How can I avoid this kind of errors without changing the entire grammar? 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. I have seen that some contrib modules (such as SEG or CUBE) define separate bison grammar rules. However, I don't understand yet how such rules integrate with the gram.y file without any conflicts. 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';)? I am new in the PostgreSQL community and any ideas for solving these problems would be very helpful. Thanks by advance, Thomas Girault -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Module extension for parsing and rewriting functions with infixed syntax
Thomas Girault 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers