Date: Tue, 19 Apr 2016 12:20:03 +0300
From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Arcadiy Ivanov <arcadiy@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Parser extensions (maybe for 10?)
Message-ID: <20160419122003.731704b2@fujitsu>
In-Reply-To: 
 <CAFj8pRAYQ_Zg6W5ia1RE7vCcOwT3XdKr0OiRoHCEfq1Vb6sycw@mail.gmail.com>
References: <570C7B5A.9070309@gmail.com>
	<5688.1460437831@sss.pgh.pa.us>
	<CAFj8pRA6hAG3kg+iANEad+7b+u_Y-Pqnaz-q0TbwBX4h=5h_Yw@mail.gmail.com>
	<20160418182523.3f70ad88@fujitsu>
	<CAFj8pRCgwN1drV0V7EWQC8eacYbF091nGpG7BGpQFaFG1mY1xg@mail.gmail.com>
	<20160418184458.51f203ab@fujitsu>
	<CAFj8pRAYQ_Zg6W5ia1RE7vCcOwT3XdKr0OiRoHCEfq1Vb6sycw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> no - it is not possible. Not with Bison parser - it cannot work with
> unknown syntax - so isn't possible implement one part by parser A, and
> second part by parser B.
> 
> But we can parsers P1 and P2. P1 knows string XX, P2 knows YY. Buildin
> parser (BP) knows SQL
> 
> We can have registered parsers P1, P2, BP.
> 
> for string SELECT
> 
> P1 fails,
> P2 fails,
> BP processes it
> 
> for string YY
> 
> P1 fails,
> P2 process it,
> BP is not called
> 
> But transformations can be allowed too (but it is slower)
> 
> for string ZZZZ
> 
> P1 does transformation to YYY
> P2 does transformation to SELECT
> BP processes it

I look on this a little bit differently.

Current pipeline is approximately like this:

```
query string -> LEX -> [lexemes] -> SYNT -> QueryAST -> PLANNER
```

Or in Haskell-like notation:

```
lex :: String -> [Lexeme]
synt :: [Lexeme] -> AST
```

Its reasonably simple to extend a lexer. Lets say that AST type doesn't
change, i.e. extensions provide only syntax sugar. After desugaring
query transforms to old-good SELECT, UPDATE, procedures calls, etc. In
this case what extension does is actually:

```
type Parser = [Lexeme] -> AST
extendParser :: Parser -> Parser
```

Can we guarantee that extensions don't conflict? In fact we can since
we already do it. If all tests pass there is no conflict.

The only tricky part I see is that sometimes we want:

```
extendParser1 ( extendParser2 ( default ))
```

... and sometimes:

```
extendParser2 ( extendParser1 ( default ))
```

I don't think that order of extension will matter most of the time. But
we still should provide a mechanism to change this order. For instance,
contribs could provide a default priority of parser extension.
Extensions with higher priority are applied first. Also user can
resolve conflicts by manually overriding these priorities:

```
select pg_parser_extension_priorities();
select pg_override_parser_extension_priority('some_extension', 100500);
```

I think it should work.

Thought?

-- 
Best regards,
Aleksander Alekseev
http://eax.me/


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers