Re: Extending PostgreSQL with a Domain-Specific Language (DSL) - Development

First of all, it's pretty difficult to follow the discussion when it's
not clear what's the original message and what's the response. E-mail
clients generally indent the original message with '>' or someting like
that, but your client does not do that (which is pretty silly). And
copying the message at the top does not really help. Please do something
about that.

On Fri, Jul 05, 2019 at 09:37:03PM +0000, Tom Mercha wrote:
>>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.
>
>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?
>

Well, I'm not an expert in that area, but we currently don't have any
infrastructure to support that. It's a topic that was discussed in the
past (perhaps you can find some references in the archives) and it
generally boils down to:

1) We're using bison as parser generator.
2) Bison does not allow adding rules on the fly.

So you have to modify the in-core src/backend/parser/gram.y and rebuild
postgres. See for example for an example of such discussion

https://www.postgresql.org/message-id/flat/CABSN6VeeEhwb0HrjOCp9kHaWm0Ljbnko5y-0NKsT_%3D5i5C2jog%40mail.gmail.com

When two of the smartest people on the list say it's a hard problem, it
probably is. Particularly for someone who does not know the internals.

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

Well, it's the only way to deal with it at the moment.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services