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