fix: parse error on unnamed arg with default syntax

[r1b]

Using the DEFAULT variant of the CREATE FUNCTION default argument syntax causes a parse error with unnamed arguments. The proposed fix skips the logic to disambiguate argname argtype from argtype when the DEFAULT keyword is detected. IIUC, this is safe because argname and argtype can only take on the name DEFAULT when quoted.

e.g, in postgres this is allowed:

CREATE DOMAIN "DEFAULT" AS int;
CREATE FUNCTION add(INTEGER, "DEFAULT" "DEFAULT" DEFAULT 1) RETURNS INTEGER LANGUAGE SQL AS 'select $1 + $2;';

But "DEFAULT" (the argname) and "DEFAULT" (the argtype) cannot appear unquoted

Ref: apache/datafusion#18450 (comment)

[r1b]

Please let me know if there is a better place for a more general fix. It seems like adding DEFAULT to RESERVED_FOR_IDENTIFIER might do the trick be necessary as well, but not sure if this is appropriate in all supported dialects.

[iffyio]

Suggested change

	if !matches!(token.token, Token::Word(_)) {
	if self.peek_keyword(DEFAULT) || !matches!(token.token, Token::Word(_)) {

thinking we can simplify the introduced if statement by doing the check here instead?

[r1b]

Won't we return a Result<_, ParserError> from parse_function_arg in this case? I was thinking we do still need to continue on to parse the default_expr. I'll take a closer look.

I agree that the nesting is not ideal in any case, maybe another option would be to push this check into maybe_parse above?

[iffyio]

Oh yeah indeed, I misread that block as happening inside of the maybe_parse. Yes the intent would be to ideally do the check in the maybe_parse I think

[r1b]

I took a stab at this in 3fc3094