Peter Eisentraut <[email protected]> writes:
> I don't really see the point of this. These are standardized functions,
> and people should be using them in the standardized ways. By adding
> parameter names, we are opening up the use of these in nonstandard and
> unportable ways. I don't think the arguments of these functions are
> terribly confusing that use of named parameters adds much value. At
> least I didn't see this argument being made.
That's certainly a reasonable concern to raise. But we're already
supporting not-standard-compliant call syntaxes. For example,
what I read in SQL2021 is
<character substring function> ::=
SUBSTRING <left paren> <character value expression> FROM <start position>
[ FOR <string length> ] [ USING <char length units> ] <right paren>
<regular expression substring function> ::=
SUBSTRING <left paren> <character value expression> SIMILAR <character value
expression>
ESCAPE <escape character> <right paren>
(no mention of SUBSTR anywhere, btw, so that one is outside the scope
of your argument). We support those syntaxes, or at least a subset of
them, but we also allow you to call substring() with just plain ol'
"substring(x, y, z)". Why shouldn't we also allow substring() with
named-argument notation? It'd arguably be a lot clearer than what the
standard proposes. Also probably more type-safe: if you look at the
substr_list production in gram.y, we're often relying on type matching
not the syntax decorations to ensure we pick the intended version of
substring().
> Furthermore, if we somehow decided to do this, let's not do it four
> functions at a time but have a general plan about whether, why, and how
> to add parameter names to built-in/standard functions.
Agreed, it would be good to have a plan about where this is going.
regards, tom lane
