Re: mixed, named notation support - Mailing list pgsql-hackers

Hello

2009/8/9 Tom Lane <tgl@sss.pgh.pa.us>:
> Now that I've started to read this patch ... exactly what is the
> argument for allowing a "mixed" notation (some of the parameters named
> and some not)?  ISTM that just serves to complicate both the patch
> and the user's-eye view, for no real benefit.
>

consider function like

foo(mandatory params without defaults, optional params with defaults)

because you have to put all mandatory params, then names are needless.
But some optional params you have to specify by names, because without
names, you have to put full params set with respect to rule about
using default params.

CREATE OR REPLACE FUNCTION strtr(a varchar, uppercase boolean = false,
lowercase boolean = false) RETURNS varchar AS $$
BEGIN IF uppercase and lowercase THEN RAISE EXCEPTION 'cannot use both
modificator together' END IF;
IF uppercase THEN RETURN upper(a); END IF;
IF lowercase THEN RETURN lower(a); END IF;
RETURN a;
END IF;
$$ LANGUAGE plpgsql IMMUTABLE STRICT;

the advice is verbosity:

SELECT strtr('some text',true, false);
versus
SELECT strtr('some text', true AS uppercase);
or
SELECT strtr('some text', true AS lowercase);

With mixed notation is very clean border betwenn mandatory and optional params.

I thing, so without mixed notation this patch hasn't any sense and I
thing it's better to drop it.

> Considering that we are worried about someday having to adjust to a
> SQL standard in this area, I think we ought to be as conservative as
> possible about what we introduce as user-visible features here.
> As an example, if they do go with "=>" as the parameter marker,
> mixed notation would become a seriously bad idea because it would be
> impossible to distinguish incidental use of => as an operator from
> mixed notation.

I am sorry, I don't understand. When => should be some operator, then
you cannot distinguish between named notation and positional notation
too. Mixed notation doesn't play any role.

foo(a => 10, b=>20) should be code in positional notation much like
named notation. ??? How is difference?

I thing so when some body use operator =>, then he have to break
standard notation for some collision situation or for all situation.
Syntax with AS is safe and should be enabled anywhere. We can simply
detect situation where operator => exists and standard named
parameters are allowed.

I thing, so we are on safe side, because we should to support both
syntax, and can disable temporary one ambiguous.

regards
Pavel Stehule

>
>                        regards, tom lane
>