On 5/11/13 11:27 AM, Tom Lane wrote:
David Fetter <da...@fetter.org> writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a clue what the design looks like.
That's a direction several of the proprietary RDBMS vendors have
proposed. I think it'd be great :)
Pre-coffee (yeah, I know. Bad idea.) sketch of an idea: create an API
to pass expression trees in and out. This could have other benefits
as to clustering space, shortening the planning cycle, etc., but let's
not go there for now. My knowledge is very, very sketchy, but when I
squint, the expression trees we use look a lot like JSON. Are they
isomorphic?
By the time you've got an expression tree, the problem is mostly solved,
at least so far as parser extension is concerned.
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.
A larger issue is that if you don't have the whole grammar available
to check, it's difficult to be sure there are no parsing conflicts.
I seem to remember that we hit some conflicts between different
extension ROMs back at HP :-(
Another point is that extensions that are actually interesting require
a lot more than new syntax. Robert mentioned the rewriter, but you'd
typically need planner and executor additions as well. It's possible to
see how whole new plan node types might be added by a plugin so far as
the executor is concerned, but I haven't a clue how we'd get the planner
to emit them ...
FWIW, I've wanted the ability to plug into the parser not for an extension, but
so that I could programmaticly enforce certain coding conventions. TBH, it
would be ideal if that was possible without requiring a backend (ie, some kind
of stand-alone library/tool), but exposing it via a backend would be better
than nothing.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
