Re: Hook for extensible parsing.

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
way.

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