From: Tom Lane <tgl@sss.pgh.pa.us>
To: Luke Muther <lmutes8@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Function Error Response Is Not Clear
In-reply-to: 
 <CACavRX+U2mZ2-K7M=QqLOJz_tzviDdvZHVBe=AXdZxCFD4_+Dw@mail.gmail.com>
References: 
 <CACavRX+U2mZ2-K7M=QqLOJz_tzviDdvZHVBe=AXdZxCFD4_+Dw@mail.gmail.com>
Comments: In-reply-to Luke Muther <lmutes8@gmail.com>
	message dated "Thu, 05 Jun 2025 22:50:23 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15084.1749312307.1@sss.pgh.pa.us>
Date: Sat, 07 Jun 2025 12:05:07 -0400
Message-ID: <15085.1749312307@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/15085.1749312307%40sss.pgh.pa.us>
Precedence: bulk

Luke Muther <lmutes8@gmail.com> writes:
> Some functions if they are missing the correct arguments give vague error
> messages while others give specific ones.

Yeah, it's difficult to move the goalposts here at reasonable cost.
The functions that you are complaining about do not go through the
normal parsing process for functions; instead they have hard-wired
grammar productions:

/*
 * Special expressions that are considered to be functions.
 */
func_expr_common_subexpr:
...
            | NULLIF '(' a_expr ',' a_expr ')'
...
            | COALESCE '(' expr_list ')'

and Bison just doesn't do any better than "syntax error" if it
cannot find a match in the grammar.  In these particular cases
we could make the grammar production more agnostic and complain
about wrong-number-of-arguments in parse analysis.  However
that idea doesn't go very far, because most of the variants of
func_expr_common_subexpr have weird SQL-spec-mandated special
syntax, eg

            | TRIM '(' trim_list ')'

...

trim_list:    a_expr FROM expr_list
            | FROM expr_list
            | expr_list
        ;

So I don't see an easy way to make more than a very small
dent in the problem.  If you're feeling motivated to
research this and look for a better answer, please do.

			regards, tom lane