Currently the parser and lexer are fully fixed at compile-time and not amenable to the extensions - extensions are only capable of introducing functions etc.
There is, however, an advantage to being able if not add or alter complete statements (which would be nice), but to at least augment portions of syntax for existing ones in some places.
I saw the following discussion in the past, but I haven’t read it:
I’m interested in the pluggable, extensible parser for two purposes. One is to add compatibility for other databases.
The other is for the ODBC (and possibly JDBC) driver.
The ODBC/JDBC specs require some unique syntax constructs, e.g. {? = call funcname(arguments)} to call stored procs/functions. Currently, the ODBC/JDBC drivers are forced to parse and convert SQL statements. It is ideal for PostgreSQL itself to understand the ODBC/JDBC syntax, and eliminate the burdon of parsing statements from the JDBC/ODBC drivers.
As recently discovered there is more than one reason why an intelligent driver, like the JDBC standard at least requires in a few instances, requires knowledge of at least some basic structure
of the statements it sees before sending them off to the server. Furthermore, and particularly in the JDBC example you provide, my first reaction is that it would be a massive encapsulation violation to try and get PostgreSQL to understand "{? = call funcname(args)}" and similar higher level API specifications.
I think PostgreSQL can do quite well by saying, hey this is what we are and this is what we do. Compatibility has merit but I'm sure at least some of those items can make it into the bison files - regardless of whether those changes end up being accepted into core. Small-scale forking like this seems like it would be easier to accomplish if not preferable to making the entire thing modular. We have that option to offer others since we are an open source project.
