Re: pl/pgsql feature request: shorthand for argument and local variable references - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id CAFj8pRC_eXkNfFiTyP4KyLOqqDdy_J-O0Zf9DS0pg6WWwgugqA@mail.gmail.com
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  (Hannu Krosing <hannuk@google.com>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references  (Hannu Krosing <hannuk@google.com>)
List pgsql-hackers


čt 18. 3. 2021 v 15:59 odesílatel Hannu Krosing <hannuk@google.com> napsal:
On Thu, Mar 18, 2021 at 3:45 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
>
> čt 18. 3. 2021 v 15:19 odesílatel Hannu Krosing <hannuk@google.com> napsal:
...
>> Variation could be
>>
>> DECLARE
>>    fnarg ALIAS FOR FUNCTION a_function_with_an_inconveniently_long_name;
>>
>> so it is clear that we are aliasing current function name
>>
>>
>> or even make the function name optional, as there can only be one, so
>>
>> DECLARE
>>    fnarg ALIAS FOR FUNCTION;
>
>
> Why you think so it is better than just
>
> #routine_label fnarg
>
> ?

It just adds already a *third* way to (re)name things, in addition to
<< blocklabel >>
and ALIAS FOR

For some reason it feels to me similar to having completely different
syntax rules
for function names, argument names and variable names instead of all having to
follow rules for "identifiers"

For cleanness/orthogonality I would also prefer the blocklables to be in DECLARE
for each block, but this train has already left :)
Though we probably could add alternative syntax ALIAS FOR BLOCK ?

why? Is it a joke?

you are defining a block label, and you want to in the same block redefine some outer label? I don't think it is a good idea.



> Maybe the name of the option can be routine_alias? Is it better for you?

I dont think the name itself is bad, as it is supposed to be used for
both FUNCTION
and PROCEDURE renaming

> My objection to DECLARE is freedom of this clause. It can be used everywhere.
> the effect of DECLARE is block limited. So theoretically somebody can write
>
> BEGIN
>   ..
>   DECLARE fnarg ALIAS FOR FUNCTION;
>   BEGIN
>     ..
>   END;
>
> END;
>
> It disallows simple implementation.

We could limit ALIAS FOR FUNCTION to outermost block only, and revisit
this later
if there are loud complaints (which I don't think there will be :) )

Inside the parser you don't know so you are in the outermost block only. 

I play with it and I see two objections against DECLARE syntax

1. the scope is in block. So you cannot use aliases for default arguments (or maybe yes, but is it correct?)

CREATE OR REPLACE FUNCTION fx(a int, b int)
RETURNS ... AS $$
DECLARE
  x1 int := fx.a;
  fnarg AS ALIAS FOR FUNCTION;
  x2 int := fnarg.a; -- should be this alias active now?
BEGIN

2. "ALIAS FOR FUNCTION" is not well named. In some languages, and in ADA language too. You can rename an external function just for current scope. You can find some examples like

DECLARE
  s ALIAS FOR FUNCTION sin;
BEGIN
  s(1); -- returns result of function sin

other example - recursive function

CREATE OR REPLACE FUNCTION some_very_long()
RETURNS int AS $$
DECLARE
  thisfx ALIAS FOR FUNCTION;
BEGIN
  var := thisfx(...);

But we don't support this feature. We are changing just a top scope's label. So syntax "ALIAS FOR FUNCTION is not good. The user can have false hopes









Cheers
Hannu

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Implement for window functions
Next
From: Zhihong Yu
Date:
Subject: Re: should INSERT SELECT use a BulkInsertState?