Pavel Stehule <pavel.steh...@gmail.com> writes:
> čt 19. 1. 2023 v 10:23 odesílatel 2903807...@qq.com <2903807...@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
