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

On 5/11/13 11:27 AM, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net