On Wed, Sep 15, 2021 at 11:26 PM Tom Lane <tgl@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?
