Re: Hook for extensible parsing.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Hook for extensible parsing.
Date: 2021-09-23 14:21:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> My POC's grammar is only like:

> CREATE HYPOTHETICAL INDEX opt_index_name ON relation_expr '(' index_params ')'
> {
> IndexStmt *n = makeNode(IndexStmt);
> n->idxname = $4;
> n->relation = $6;
> n->accessMethod = DEFAULT_INDEX_TYPE;
> n->indexParams = $8;
> n->options = list_make1(makeDefElem("hypothetical", NULL, -1));
> $$ = (Node *) n;
> }

I'm not too impressed by this example, because there seems little
reason why you couldn't just define "hypothetical" as an index_param
option, and not need to touch the grammar at all.

> as I'm not willing to import the whole CREATE INDEX grammar for now for a patch
> that may be rejected.

The fact that that's so daunting seems to me to be a perfect illustration
of the problems with this concept. Doing anything interesting with a
hook like this will create a maintenance nightmare, because you'll have
to duplicate (and track every change in) large swaths of gram.y. To the
extent that you fail to, say, match every detail of the core's expression
grammar, you'll be creating a crappy user experience.

> that once my parser returns this parse tree, all I need to do is intercept
> IndexStmt containing this option in a utility_hook and run my code rather than
> a plain DefineIndex(), which works as intended as I showed above.

And I'm even less impressed by the idea of half a dozen extensions
each adding its own overhead to the parser and also to ProcessUtility
so that they can process statements in this klugy, highly-restricted

I do have sympathy for the idea that extensions would like to define
their own statement types. I just don't see a practical way to do it
in our existing parser infrastructure. This patch certainly doesn't
offer that.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2021-09-23 14:49:51 Re: mark the timestamptz variant of date_bin() as stable
Previous Message Tony Zhu 2021-09-23 13:55:30 Re: [Proposal] Global temporary tables