Re: Function Error Response Is Not Clear

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Luke Muther <lmutes8(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Function Error Response Is Not Clear
Date: 2025-06-07 16:05:07
Message-ID: 15085.1749312307@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Luke Muther <lmutes8(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-06-07 16:08:44 BUG #18950: pgsql function that worked in Postgresql 16 does not return in Postgresql 17
Previous Message Dilip Kumar 2025-06-07 15:55:24 Re: BUG #18949: 分区表创建主键或者唯一约束需要有分区键