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 ...
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
