feat: Allow OUTER keyword as function parameter name

[mountaincrab]

Context

SQL keywords are sometimes allowed as parameter names in table functions. For example, the following statement is valid on Snowflake:

INSERT INTO db.schema.target
    (Name, FriendParent)
SELECT
    i.DATA_VALUE:Name AS Name,
    f1.Value:Parent:Name AS FriendParent
FROM
    db.schema.source AS i,
    flatten(input => i.DATA_VALUE:Friends, outer => true) AS f1

Note that the second named parameter passed to the table function flatten is outer, which is a SQL keyword, and it is unquoted.

Currently, statements like this fail to parse, I think because SQL keywords are not allowed as parameter names. However, as this is a valid statement, I'd like to be able to parse it.

Details

The production in the grammar which handles named parameters is OracleNamedFunctionParameter. Currently, this is using the RelObjectNameExt2 production to match the parameter name. I think (although I don't understand how) this does not match keywords. Since parameter names are not objects, I thought we could use the <S_IDENTIFIER> token, which looks like it should match something like outer. However, this doesn't appear to match keywords, again I don't understand how - looking at the <S_IDENTIFIER> token, it looks like it will match any sequence of unicode characters 🤔 . As a simple (probably wrong) solution, I've manually added the <K_OUTER> token as a possible match in OracleNamedFunctionParameter:

( name=RelObjectNameExt2() | token=<K_OUTER> )

But this feels wrong. I don't think parameter names necessarily need to be valid object names, hence why I wanted to use <S_IDENTIFIER>, but I can't work out why <S_IDENTIFIER> won't match keywords. Happy to discuss this further, any help would be much appreciated!

[manticore-projects]

Thank you for your contribution, very clean and efficient.
Please resolve the QA exceptions on formatting and I will merge,

[mountaincrab]

Thank you for your contribution, very clean and efficient. Please resolve the QA exceptions on formatting and I will merge,

Thanks for the speedy response @manticore-projects 😁 I just wanted to double check you're happy with the solution. As explained in the PR description, I don't think it's ideal! I feel like we could do it a better way e.g. just using <S_IDENTIFIER>, but I'm not quite sure how...

[manticore-projects]

Thank you for your contribution, very clean and efficient. Please resolve the QA exceptions on formatting and I will merge,

Thanks for the speedy response @manticore-projects 😁 I just wanted to double check you're happy with the solution. As explained in the PR description, I don't think it's ideal! I feel like we could do it a better way e.g. just using <S_IDENTIFIER>, but I'm not quite sure how...

I know its not ideal, but it is efficient and fixes the problem right now while maintaining the options for improving it later.
The real solution was another production AllowedFunctionArgumentTokens, derived from RelObjectNameExt2 and adding the extra tokens there. But that takes time to do properly.

[mountaincrab]

OK sounds good, as long as you're happy 😁 Will get the formatting sorted 👍

[mountaincrab]

That should be all sorted now!

[manticore-projects]

Thank you again for your contribution!