Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQWoS-0001dw-Vo for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Sep 2021 15:27:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mQWoP-0006mw-Pi for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Sep 2021 15:27:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQWoP-0006mj-I0 for pgsql-hackers@lists.postgresql.org; Wed, 15 Sep 2021 15:27:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQWoN-0001Ww-8s for pgsql-hackers@lists.postgresql.org; Wed, 15 Sep 2021 15:27:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 18FFQugr984301; Wed, 15 Sep 2021 11:26:56 -0400 From: Tom Lane To: Jim Mlodgenski cc: Simon Riggs , Julien Rouhaud , PostgreSQL Developers Subject: Re: Hook for extensible parsing. In-reply-to: References: <20210501072458.adqjoaqnmhg4l34l@nol> Comments: In-reply-to Jim Mlodgenski message dated "Wed, 15 Sep 2021 10:14:38 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <984299.1631719616.1@sss.pgh.pa.us> Date: Wed, 15 Sep 2021 11:26:56 -0400 Message-ID: <984300.1631719616@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jim Mlodgenski writes: > On Wed, Sep 15, 2021 at 9:25 AM Simon Riggs > wrote: >> The general rule has always been that we don't just put hooks in, we >> always require an in-core use for those hooks. I was reminded of that >> myself recently. > That's not historically what has happened. There are several hooks with > no in core use such as emit_log_hook and ExplainOneQuery_hook. Yeah. I think the proper expectation is that there be a sufficiently worked-out example to convince us that the proposed hooks have real-world usefulness, and are not missing any basic requirements to make them do something useful. Whether the example ends up in our tree is a case-by-case decision. In the case at hand, what's troubling me is that I don't see any particular use in merely substituting a new bison grammar, if it still has to produce parse trees that the rest of the system will understand. Yeah, you could make some very simple surface-syntax changes that way, but it doesn't seem like you could do anything interesting (like, say, support Oracle-style outer join syntax). AFAICS, to get to a useful feature, you'd then need to invent an extensible Node system (which'd be hugely invasive if it's feasible at all), and then probably more things on top of that. So I'm not convinced that you've demonstrated any real-world usefulness. regards, tom lane