Re: Extending PostgreSQL with a Domain-Specific Language (DSL) -Development - Mailing list pgsql-hackers

On Sun, Jul 07, 2019 at 11:06:38PM +0000, Tom Mercha wrote:
>On 06/07/2019 00:06, Tomas Vondra wrote:
>> 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.
>
>I would like to apologise. I did not realize that my client was doing
>that and now I have changed the client. I hope it's fine now.
>

Thanks, seems fine now.

>>
>> 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.
>You are right. Thanks for bringing it to my attention!
>
>I didn't design my language for interaction with triggers and whatnot,
>but I think that it would be very interesting to support those as well,
>so looking at CREATE LANGUAGE functionality is actually exciting and
>appropriate once I make some changes in design. Thanks again for this point!
>

;-)

>I hope this is not off topic but I was wondering if you know what are
>the intrinsic differences between HANDLER and INLINE parameters of
>CREATE LANGUAGE? I know that they are functions which are invoked at
>different instances of time (e.g. one is for handling anonymous code
>blocks), but at the end of the day they seem to have the same purpose?
>

I've never written any PL handler, so I don't know. All I know is this
quote from the docs, right below the simple example of PL handler:

    Only a few thousand lines of code have to be added instead of the
    dots to complete the call handler.

I suppose the best idea to start an implementation is to copy an
existing PL implementation, and modify that. That's usually much easier
than starting from scratch, because you have something that works. Not
sure if PL/pgSQL is the right choice though, perhaps pick some other
language from https://wiki.postgresql.org/wiki/PL_Matrix


regards

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