Re: pl/pgsql feature request: shorthand for argument and local variable references

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Vik Fearing <vik(at)postgresfriends(dot)org>, Chapman Flack <chap(at)anastigmatix(dot)net>, Jack Christensen <jack(at)jncsoftware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references
Date: 2021-03-17 06:06:57
Message-ID: 20210317060657.242n5qripp5mu33i@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 17, 2021 at 05:30:30AM +0100, Pavel Stehule wrote:
> st 17. 3. 2021 v 4:52 odesílatel Michael Paquier <michael(at)paquier(dot)xyz>
>
> > I am wondering whether it would be better to allow multiple aliases
> > though, and if it would bring more readability to the routines written
> > if these are treated equal to the top-most namespace which is the
> > routine name now, meaning that we would maintain not one, but N top
> > namespace labels that could be used as aliases of the root one.
> >
>
> I do not have a strong opinion, but I am inclined to disallow this. I am
> afraid so code can be less readable.
>
> There is a precedent - SQL doesn't allow you to use table names as
> qualifiers when you have an alias.

+1

>
> But it is a very important question. The selected behavior strongly impacts
> an implementation.
>
> What is the more common opinion about it? 1. Should we allow the original
> top label or not? 2. Should we allow to define more top labels?

I also think that there should be a single usable top label, otherwise it will
lead to confusing code and it can be a source of bug.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-03-17 06:31:37 Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL
Previous Message Thomas Munro 2021-03-17 05:58:02 Re: Assertion failure with barriers in parallel hash join