How to AT_LEAST_ONE without repeats

[timneedham]

Hi,

First of all - I very much love Chevrotain, great work thank you! ❤️
I've come a little unstuck and not quite sure how to progress, any pointers would be really appreciated.

I'm trying to parse this PostgreSQL command:

https://www.postgresql.org/docs/current/sql-grant.html

For example, in this form:

GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
    [, ...] | ALL [ PRIVILEGES ] }
    ON { [ TABLE ] table_name [, ...]
         | ALL TABLES IN SCHEMA schema_name [, ...] }
    TO role_specification [, ...] [ WITH GRANT OPTION ]
    [ GRANTED BY role_specification ]

...we can see this is valid:

GRANT SELECT, INSERT, TRIGGER ON TABLE emp TO me;

However, I'm not sure how to model/express { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER } [, ...] in Chevrotain (AT_LEAST_ONE_SEP has served me well, but I'm struggling to enforce the "no repeated values" requirement and there can be ambiguity with other forms of the command which have shared values like SELECT).

• I suspect some creative use of parameterized rules and gates is the way to go.

Any pointers warmly welcomed!

Thanks

[msujew]

Hey @timneedham,

I usually don't recommend performing this sort of work in the parser at all. Of course it depends on your use case, but in my line of work (writing language support for language servers/IDEs), building such "no repeats" rules into the parser usually yields uninterpreterable parser errors for the user. My personal recommendation would be to have a validation phase performed on the output of the parser to validate that certain rules are being followed by the input.

If you're dead set on doing this work in the parser, here's my advice:

I suspect some creative use of parameterized rules and gates is the way to go.

Yes, that would probably be the way to go. We do something similar in Langium with unordered groups. The implementation is relatively straightforward:

const set = new Set<number>();
this.AT_LEAST_ONE(() => {
  this.OR([
    {
      GATE: () => !set.has(0),
      ALT: () => {
        set.add(0);
        this.CONSUME(SELECT_TOKEN);
      }
    },
    {
      GATE: () => !set.has(1),
      ALT: () => {
        set.add(1);
        this.CONSUME(INSERT_TOKEN);
      }
    },
    {
      GATE: () => !set.has(2),
      ALT: () => {
        set.add(2);
        this.CONSUME(UPDATE_TOKEN);
      }
    },
    ...
  ]);
});

If you are doing the OR inside of a dedicated rule, you'll need to add parameters and pass the set into it. That should work as expected.

[timneedham]

Brilliant, thanks for the help @msujew ! 🙏

I'm more than happy to do it in a later validation phase, but when I tried that things became ambiguous, as two different forms of the GRANT command share values in their "sets".

For example, SELECT can appear in both TABLE and SEQUENCE forms:

GRANT SELECT, INSERT, TRIGGER ON TABLE emp TO me;
GRANT SELECT ON SEQUENCE  my_seq TO me;

Without any expressing "no duplicates" in AT_LEAST_ONE I'm finding GRANT SELECT, SELECT, SELECT, SELECT ON SEQUENCE my_seq TO me; will parse.

If failing-with-duplicates is handled on a subsequent validation phase, I then hit ambiguity when Chevrotain is tries to distinguish between the two different forms (as GRANT SELECT, SELECT, SELECT, SELECT is valid for both TABLE and SEQUENCE forms).

Ah! 💡

I should refactor the grammar so there aren't any explicit "forms" and push validation of the "set" in relation to TABLE, SEQUENCE etc. to a later phase too, that's the way to go, isn't it?

* I'll edit my original issue as the "proxy" issue has since proved irrelevant 😊

[msujew]

Are GRANT ... ON TABLE and GRANT ... ON SEQUENCE separate rules? In this case you'll always get an ambiguity error in Chevrotain due to the unknown-length common prefix. You should definitely refactor this into a single rule to prevent the prefix issue.

I should refactor the grammar so there aren't any explicit "forms" and push validation of the "set" in relation to TABLE, SEQUENCE etc. to a later phase too, that's the way to go, isn't it?

Essentially, yes.

[timneedham]

Are GRANT ... ON TABLE and GRANT ... ON SEQUENCE separate rules?

Yup! Cool, thanks @msujew , very much appreciated.