On 09/07/2019 23:22, Tomas Vondra wrote: > 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 >
I understand that you never wrote any PL handler but was just thinking about this functionality as a follow-up to our conversation. I was just wondering whether anonymous DO blocks *must* return void or not? The docs for DO say it is a function returning void - https://www.postgresql.org/docs/current/sql-do.html But the docs for CREATE LANGUAGE's INLINE HANDLER say 'typically return void' - https://www.postgresql.org/docs/current/sql-createlanguage.html Is the implication that we can make the DO block return something somehow? I would be quite interested if there is a way of achieving this kind of functionality. My experiments using an SRF, which I have written, within an anonymous DO block just gives me an "ERROR: set-valued function called in context that cannot accept a set". Anyway maybe I'm going off on a tangent here... perhaps it is better to open a new thread? > > regards >
