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
|
| 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: