Re: Support plpgsql multi-range in conditional control - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Support plpgsql multi-range in conditional control
Date
Msg-id 4060854.1674141817@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support plpgsql multi-range in conditional control  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> čt 19. 1. 2023 v 10:23 odesílatel 2903807914@qq.com <2903807914@qq.com>
> napsal:
>> Dear hackers, my good friend Hou Jiaxing and I have implemented a version
>> of the code that supports multiple integer range conditions in the in
>> condition control of the for loop statement in the plpgsql procedural
>> language. A typical example is as follows:

> I don't like it. The original design of ADA language is to be a safe and
> simple language. Proposed design is in 100% inversion.

Yeah, I'm pretty dubious about this too.  plpgsql's FOR-loop syntax is
already badly overloaded, to the point where it's hard to separate
the true intent of a statement.  We have very ad-hoc rules in there
like "if the first thing after IN is a var of type refcursor, then
it's FOR-IN-cursor, otherwise it couldn't possibly be that".  (So
much for functions returning refcursor, for example.)  Similarly the
"FOR x IN m..n" syntax has a shaky assumption that ".." couldn't
possibly appear in mainline SQL.  If you make any sort of syntax
error you're likely to get a very unintelligible complaint --- or
worse, it might take it and do something you did not expect.

I fear that allowing more complexity in "FOR x IN m..n" will make
those problems even worse.  The proposed patch gives comma a special
status akin to ".."'s, but comma definitely *can* appear within SQL
expressions --- admittedly, it should only appear within parentheses,
but now you're reliant on the user keeping their parenthesization
straight in order to avoid going off into the weeds.  I think this
change increases the chances of confusion with FOR-IN-SELECT as well.

If there were a compelling use-case for what you suggest then
maybe it'd be worth accepting those risks.  But I share Pavel's
opinion that there's little use-case.  We've not heard a request
for such a feature before, AFAIR.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CREATEROLE users vs. role properties
Next
From: Robert Haas
Date:
Subject: Re: almost-super-user problems that we haven't fixed yet