Re: Proposal to add --single-row to psql

On 5/11/13 11:27 AM, Tom Lane wrote:
> David Fetter <david@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
certaincoding conventions. TBH, it would be ideal if that was possible without requiring a backend (ie, some kind of
stand-alonelibrary/tool), but exposing it via a backend would be better than nothing.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net