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 CAFj8pRD_9+LL3EMno7FCsvEm7X3NAa2eRGF1BYd5cSFEau_a8Q@mail.gmail.com
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references
List pgsql-hackers


čt 6. 1. 2022 v 14:28 odesílatel Joel Jacobson <joel@compiler.org> napsal:
On Thu, Jan 6, 2022, at 10:05, Julien Rouhaud wrote:
> I agree, but on the other hand I don't see how defining a top level block
> alias identical for every single plpgsql function would really make sense.
> Not every function has a very long name and would benefit from it, and no one
> can really assume that e.g. "root" or whatever configured name won't be used in
> any plpgsql function on that database or cluster.  So while having some global
> configuration infrastructure can be useful I still don't think that it could be
> used for this purpose.

How about using the existing reserved keyword "in" followed by "." (dot) and then the function parameter name?

This idea is based on the assumption "in." would always be a syntax error everywhere in both SQL and PL/pgSQL,
so if we would introduce such a syntax, no existing code could be affected, except currently invalid code.

I wouldn't mind using "in." to refer to IN/OUT/INOUT parameters and not only IN ones, it's a minor confusion that could be explained in the docs.

You are right, in.outvar looks messy. Moreover, maybe the SQL parser can have a problem with it.

Regards

Pavel


 

Also, "out." wouldn't work, since "out" is not a reserved keyword.

/Joel

pgsql-hackers by date:

Previous
From: "Finnerty, Jim"
Date:
Subject: Re: ICU for global collation
Next
From: Simon Riggs
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15