From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "2903807914(at)qq(dot)com" <2903807914(at)qq(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, 1276576182 <1276576182(at)qq(dot)com> |
Subject: | Re: Support plpgsql multi-range in conditional control |
Date: | 2023-01-19 15:23:37 |
Message-ID: | 4060854.1674141817@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> čt 19. 1. 2023 v 10:23 odesílatel 2903807914(at)qq(dot)com <2903807914(at)qq(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-01-19 15:31:57 | Re: almost-super-user problems that we haven't fixed yet |
Previous Message | Robert Haas | 2023-01-19 15:20:33 | Re: CREATEROLE users vs. role properties |