On Sat, May 11, 2013 at 07:22:55PM -0400, Robert Haas wrote:
> On Sat, May 11, 2013 at 12:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > By the time you've got an expression tree, the problem is mostly solved,
> > at least so far as parser extension is concerned.
>
> Right.
>
> > More years ago than I care to admit, I worked on systems that had
> > run-time-extensible parsers at Hewlett-Packard, so technology for this
> > does exist. But my (vague) memory of those systems is that the parser's
> > language capabilities were more limited than bison's, perhaps only
> > LL(1). Parsing spec-compatible SQL that way might be a challenge.
>
> If I understand bison correctly, it basically looks at the current
> parser state and the next token and decides to either shift that token
> onto the stack or reduce the stack using some rule. If there's no
> matching rule, we error out. If someone wants to inject new rules
> into the grammar, those state tables are all going to change. But if
> we could contrive things so that the state tables are built
> dynamically and can be change as rules are added and removed, then it
> seems to me that we could let a loadable module supply (or delete)
> whatever grammar rules it likes. Whenever it does this, we recompile
> the grammar on next use (and complain if we get ambiguities). This
> does not sound all that easy to code, but at least in theory it seems
> doable.
>
> We'd also need a way to add keywords. To be quite frank, I think our
> whole approach to keywords is massive screwed up right now. Aside
FYI, one trick that is often used when parsing C code is to allow parsed
code to add to the keyword list, so when the parser goes to get the next
token, it might get "keyword" back based on what it has seen already.
This is required to handle C typedefs, and might be a method we could
use.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
