Martijn van Oosterhout <firstname.lastname@example.org> writes:
> On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
>> Given the nonextensibility of gram.y and keywords.c, it has to be in
>> core to even think about having special syntax :-(
> Has anyone ever heard of extensible grammers?
Yeah, I worked with systems that could do that at Hewlett-Packard, nigh
thirty years ago ... but they were much less pleasant to use than bison,
and if memory serves, slower and more limited in what they could parse
(something narrower than LALR(1), IIRC, which would make certain parts
of SQL even hairier to parse than they are now). I'm not in a big hurry
to go there, even though it would certainly take some of the steam out
of "I want this in core" arguments.
> ... decree that commands beginning with @ are extensions and are parsed
> by the module listed next. Then your command set becomes:
> @tsearch CREATE PARSER ....
This'd only work well for trivial standalone commands; as a counterexample
consider CREATE INDEX, which requires access to the core sub-grammars
for typename and expression. The SQL2003 XML additions couldn't be
handled this way either.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not