On Wed, Sep 15, 2021 at 11:26 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.
I agree that this patchset can only implement syntactic sugars, nothing more (although for utility command you can do a bit more than that). But that's already something people can use, mostly for migration to postgres use cases probably. I'm not sure why you couldn't implement an Oracle-style outer join with such a hook? The requirement is that the parser can't leak any node that the rest of the system doesn't know about, but you can do what you want inside the parser. And as far as I can see we already have an extensible node since bcac23de73b, so it seems to me that there's enough infrastructure to handle this kind of use case. The main downside is that you'll have to make a first pass to transform your "custom raw statement" into a valid RawStmt in your parser, and the system will do another one to transform it in a Query. But apart from that it should work. Am I missing something?
