From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)compiler(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pl/pgsql feature request: shorthand for argument and local variable references |
Date: | 2022-01-06 14:05:12 |
Message-ID: | CAFj8pRD_9+LL3EMno7FCsvEm7X3NAa2eRGF1BYd5cSFEau_a8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
čt 6. 1. 2022 v 14:28 odesílatel Joel Jacobson <joel(at)compiler(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2022-01-06 14:09:35 | Re: Add 64-bit XIDs into PostgreSQL 15 |
Previous Message | Finnerty, Jim | 2022-01-06 13:55:55 | Re: ICU for global collation |