Re: Extending PostgreSQL with a Domain-Specific Language (DSL) -Development - Mailing list pgsql-hackers
| From | Tom Mercha |
|---|---|
| Subject | Re: Extending PostgreSQL with a Domain-Specific Language (DSL) -Development |
| Date | |
| Msg-id | AM6PR04MB554432E65A1B9B778DB11B4CF4F50@AM6PR04MB5544.eurprd04.prod.outlook.com Whole thread Raw |
| In response to | Re: Extending PostgreSQL with a Domain-Specific Language (DSL) -Development (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
| Responses |
Re: Extending PostgreSQL with a Domain-Specific Language (DSL) -Development
(Tomas Vondra <tomas.vondra@2ndquadrant.com>)
|
| List | pgsql-hackers |
I might be missing something, but it seems like you intend to replace
the SQL grammar we have with something else. It's not clear to me what
would be the point of doing that, and it definitely looks like a huge
amount of work - e.g. we don't have any support for switching between
two distinct grammars the way you envision, and just that alone seems
like a multi-year project. And if you don't have that capability, allexternal tools kinda stop working. Good luck with running such database.
I was considering having two distinct grammars as an option - thanks for indicating the effort involved. At the end of the day I want both my DSL and the PostgreSQL grammars to coexist. Is extending PostgreSQL's grammar with my own through the PostgreSQL extension infrastructure worth consideration or is it also difficult to develop? Could you suggest any reference material on this topic?
What I'd look at first is implementing the grammar as a procedural
language (think PL/pgSQL, pl/perl etc.) implementing whatever you expect
from your DSL. And it's not like you'd have to wrap everything in
functions, because we have anonymous DO blocks.
Thanks for pointing out this direction! I think I will indeed adopt this approach especially if directly extending PostgreSQL grammar would be difficult.
Regards
Tom
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Sent: 05 July 2019 20:48
To: Tom Mercha
Cc: pgsql-hackers@postgresql.org
Subject: Re: Extending PostgreSQL with a Domain-Specific Language (DSL) - Development
Sent: 05 July 2019 20:48
To: Tom Mercha
Cc: pgsql-hackers@postgresql.org
Subject: Re: Extending PostgreSQL with a Domain-Specific Language (DSL) - Development
On Fri, Jul 05, 2019 at 07:55:15AM +0000, Tom Mercha wrote:
>Dear Hackers
>
>I am interested in implementing my own Domain Specific Language (DSL)
>using PostgreSQL internals. Originally, the plan was not to use
>PostgreSQL and I had developed a grammar and used ANTLRv4 for parser
>work and general early development.
>
>Initially, I was hoping for a scenario where I could have PostgreSQL's
>parser to change grammar (e.g. SET parser_language=SQL vs. SET
>parser_language=myDSL) in which case my ANTLRv4 project would override
>the PostgreSQL parser module. I guess another direction that my project
>could take is to extend PostgreSQL's SQL parser to factor in my DSL
>keywords and requirements.
>
>To make matters more complicated, this version of ANTLR does not
>support code generation to C, but it does support generation to C++.
>Integrating the generated C++ code requires making it friendly to
>PostgreSQL e.g. using Plain Old Data Structures as described here
>https://www.postgresql.org/docs/9.0/extend-cpp.html, which seems to be
>suggesting to me that I may be using the wrong approach towards my
>goal.
>
>I would be grateful if anyone could provide any general advice or
>pointers regarding my approach, for example regarding development
>effort, so that the development with PostgreSQL internals can be smooth
>and of a high quality. Maybe somebody has come across another DSL
>attempt which used PostgreSQL and that I could follow as a reference?
>
I might be missing something, but it seems like you intend to replace
the SQL grammar we have with something else. It's not clear to me what
would be the point of doing that, and it definitely looks like a huge
amount of work - e.g. we don't have any support for switching between
two distinct grammars the way you envision, and just that alone seems
like a multi-year project. And if you don't have that capability, all
external tools kinda stop working. Good luck with running such database.
What I'd look at first is implementing the grammar as a procedural
language (think PL/pgSQL, pl/perl etc.) implementing whatever you expect
from your DSL. And it's not like you'd have to wrap everything in
functions, because we have anonymous DO blocks. So you could do:
DO LANGUAGE mydsl $$
... whatever my dsl allows ...
$$;
It's still a fair amount of code to implement this (both the PL handler
and the DSL implementation), but it's orders of magnitude simpler than
what you described.
See https://www.postgresql.org/docs/current/plhandler.html for details
about how to write a language handler.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>Dear Hackers
>
>I am interested in implementing my own Domain Specific Language (DSL)
>using PostgreSQL internals. Originally, the plan was not to use
>PostgreSQL and I had developed a grammar and used ANTLRv4 for parser
>work and general early development.
>
>Initially, I was hoping for a scenario where I could have PostgreSQL's
>parser to change grammar (e.g. SET parser_language=SQL vs. SET
>parser_language=myDSL) in which case my ANTLRv4 project would override
>the PostgreSQL parser module. I guess another direction that my project
>could take is to extend PostgreSQL's SQL parser to factor in my DSL
>keywords and requirements.
>
>To make matters more complicated, this version of ANTLR does not
>support code generation to C, but it does support generation to C++.
>Integrating the generated C++ code requires making it friendly to
>PostgreSQL e.g. using Plain Old Data Structures as described here
>https://www.postgresql.org/docs/9.0/extend-cpp.html, which seems to be
>suggesting to me that I may be using the wrong approach towards my
>goal.
>
>I would be grateful if anyone could provide any general advice or
>pointers regarding my approach, for example regarding development
>effort, so that the development with PostgreSQL internals can be smooth
>and of a high quality. Maybe somebody has come across another DSL
>attempt which used PostgreSQL and that I could follow as a reference?
>
I might be missing something, but it seems like you intend to replace
the SQL grammar we have with something else. It's not clear to me what
would be the point of doing that, and it definitely looks like a huge
amount of work - e.g. we don't have any support for switching between
two distinct grammars the way you envision, and just that alone seems
like a multi-year project. And if you don't have that capability, all
external tools kinda stop working. Good luck with running such database.
What I'd look at first is implementing the grammar as a procedural
language (think PL/pgSQL, pl/perl etc.) implementing whatever you expect
from your DSL. And it's not like you'd have to wrap everything in
functions, because we have anonymous DO blocks. So you could do:
DO LANGUAGE mydsl $$
... whatever my dsl allows ...
$$;
It's still a fair amount of code to implement this (both the PL handler
and the DSL implementation), but it's orders of magnitude simpler than
what you described.
See https://www.postgresql.org/docs/current/plhandler.html for details
about how to write a language handler.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql-hackers by date: