From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Arcadiy Ivanov <arcadiy@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Parser extensions (maybe for 10?)
Date: Tue, 19 Apr 2016 12:20:03 +0300
Message-ID: <20160419122003.731704b2@fujitsu> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.alekseev@postgrespro.ru, pavel.stehule@gmail.com, tgl@sss.pgh.pa.us, arcadiy@gmail.com
Subject: Re: Parser extensions (maybe for 10?)
In-Reply-To: <20160419122003.731704b2@fujitsu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox