Thread: fori stmt with by keyword was:(Re: [HACKERS] for statement, adding a STEP clause?)
fori stmt with by keyword was:(Re: [HACKERS] for statement, adding a STEP clause?)
From
"Jaime Casanova"
Date:
On 4/29/06, Andrew Dunstan <andrew@dunslane.net> wrote:
> Tom Lane wrote:
>
> >"Jaime Casanova" <systemguards@gmail.com> writes:
> >
> >
> >>there is a chance to add a STEP clause to the FOR statement in plpgsql?
> >>
> >>
> >
> >This is not free: it'd require making STEP a reserved word (at least
> >within plpgsql) which is contrary to spec. I think you need to make
> >a pretty good case why the value of the feature outweighs breaking
> >applications that have perfectly-legally used "step" as an identifier.
> >
> >
>
> This isn't available in PL/SQL, is it? That doesn't mean we shouldn't do it, of course, but it might lessen any
perceivedimperative.
>
> Maybe using BY instad of STEP as the keyword would make it easier, since its occurrence in SQL makes it less likely
tobe used as a variable.
>
> cheers
>
> andrew
>
>
Hi,
i make a little patch using BY instead of STEP per Tom's complaint and
Andrew's suggestion.
the patch is not ready yet because i can't figure out how to make the
BY optional and that is mandatory because backward compatibility...
the problem is how to manage it in gram.y
perhaps someone with more expertise in gram.y can make suggestions?
also, you can review the patch and say if it will be added if i can
solve the optional BY problem... then i can start working in fixing
the docs
--
regards,
Jaime Casanova
"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz
Attachment
Re: fori stmt with by keyword was:(Re: [HACKERS] for statement, adding a STEP clause?)
From
"Jaime Casanova"
Date:
On 4/30/06, Jaime Casanova <systemguards@gmail.com> wrote:
> On 4/29/06, Andrew Dunstan <andrew@dunslane.net> wrote:
> > Tom Lane wrote:
> >
> > >"Jaime Casanova" <systemguards@gmail.com> writes:
> > >
> > >
> > >>there is a chance to add a STEP clause to the FOR statement in plpgsql?
> > >>
> > >>
> > >
> > >This is not free: it'd require making STEP a reserved word (at least
> > >within plpgsql) which is contrary to spec. I think you need to make
> > >a pretty good case why the value of the feature outweighs breaking
> > >applications that have perfectly-legally used "step" as an identifier.
> > >
> > >
> >
> > This isn't available in PL/SQL, is it? That doesn't mean we shouldn't do it, of course, but it might lessen any
perceivedimperative.
> >
> > Maybe using BY instad of STEP as the keyword would make it easier, since its occurrence in SQL makes it less likely
tobe used as a variable.
> >
> > cheers
> >
> > andrew
> >
> >
>
> Hi,
>
> i make a little patch using BY instead of STEP per Tom's complaint and
> Andrew's suggestion.
>
the patch is ready, at least it seems to me... also i have added some
lines to the docs...
let me know what your decision is about this...
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
Attachment
I went to test this patch and got the attached regression failures. Please repair and resubmit. Thanks. --------------------------------------------------------------------------- Jaime Casanova wrote: > On 4/30/06, Jaime Casanova <systemguards@gmail.com> wrote: > > On 4/29/06, Andrew Dunstan <andrew@dunslane.net> wrote: > > > Tom Lane wrote: > > > > > > >"Jaime Casanova" <systemguards@gmail.com> writes: > > > > > > > > > > > >>there is a chance to add a STEP clause to the FOR statement in plpgsql? > > > >> > > > >> > > > > > > > >This is not free: it'd require making STEP a reserved word (at least > > > >within plpgsql) which is contrary to spec. I think you need to make > > > >a pretty good case why the value of the feature outweighs breaking > > > >applications that have perfectly-legally used "step" as an identifier. > > > > > > > > > > > > > > This isn't available in PL/SQL, is it? That doesn't mean we shouldn't do it, of course, but it might lessen any perceivedimperative. > > > > > > Maybe using BY instad of STEP as the keyword would make it easier, since its occurrence in SQL makes it less likelyto be used as a variable. > > > > > > cheers > > > > > > andrew > > > > > > > > > > Hi, > > > > i make a little patch using BY instead of STEP per Tom's complaint and > > Andrew's suggestion. > > > > the patch is ready, at least it seems to me... also i have added some > lines to the docs... > > let me know what your decision is about this... > > -- > regards, > Jaime Casanova > > "Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs and the universe trying > to produce bigger and better idiots. > So far, the universe is winning." > Richard Cook -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + *** ./expected/plpgsql.out Tue May 30 07:58:19 2006 --- ./results/plpgsql.out Tue May 30 08:13:52 2006 *************** *** 1466,1474 **** --- 1466,1482 ---- -- ethernet interface into the wall and patch it to the hub. -- insert into Hub values ('base.hub1', 'Patchfield PF0_1 hub', 16); + ERROR: syntax error at or near "�" + LINE 1: �J�H�#��F + ^ + QUERY: �J�H�#��F + CONTEXT: PL/pgSQL function "tg_hub_adjustslots" line 9 at for with integer loopvar + PL/pgSQL function "tg_hub_a" line 6 at assignment insert into System values ('orion', 'PC'); insert into IFace values ('IF', 'orion', 'eth0', 'WS.002.1b'); update PSlot set slotlink = 'HS.base.hub1.1' where slotname = 'PS.base.b2'; + ERROR: HS.base.hub1.1 does not exist + CONTEXT: PL/pgSQL function "tg_slotlink_a" line 16 at assignment -- -- Now we take a look at the patchfield -- *************** *** 1482,1488 **** PF0_1 | PS.base.a5 | WS.001.3a in room 001 -> - | - PF0_1 | PS.base.a6 | WS.001.3b in room 001 -> - | - PF0_1 | PS.base.b1 | WS.002.1a in room 002 -> Phone PH.hc002 (Hicom standard) | PS.base.ta5 -> Phone line -103 ! PF0_1 | PS.base.b2 | WS.002.1b in room 002 -> orion IF eth0 (PC) | Patchfield PF0_1 hub slot 1 PF0_1 | PS.base.b3 | WS.002.2a in room 002 -> Phone PH.hc003 (Hicom standard) | PS.base.tb2 -> Phone line -106 PF0_1 | PS.base.b4 | WS.002.2b in room 002 -> - | - PF0_1 | PS.base.b5 | WS.002.3a in room 002 -> - | - --- 1490,1496 ---- PF0_1 | PS.base.a5 | WS.001.3a in room 001 -> - | - PF0_1 | PS.base.a6 | WS.001.3b in room 001 -> - | - PF0_1 | PS.base.b1 | WS.002.1a in room 002 -> Phone PH.hc002 (Hicom standard) | PS.base.ta5 -> Phone line -103 ! PF0_1 | PS.base.b2 | WS.002.1b in room 002 -> orion IF eth0 (PC) | - PF0_1 | PS.base.b3 | WS.002.2a in room 002 -> Phone PH.hc003 (Hicom standard) | PS.base.tb2 -> Phone line -106 PF0_1 | PS.base.b4 | WS.002.2b in room 002 -> - | - PF0_1 | PS.base.b5 | WS.002.3a in room 002 -> - | - *************** *** 1530,1540 **** ERROR: illegal slotlink beginning with XX CONTEXT: PL/pgSQL function "tg_slotlink_a" line 16 at assignment insert into HSlot values ('HS', 'base.hub1', 1, ''); ! ERROR: duplicate key violates unique constraint "hslot_name" insert into HSlot values ('HS', 'base.hub1', 20, ''); ERROR: no manual manipulation of HSlot delete from HSlot; - ERROR: no manual manipulation of HSlot insert into IFace values ('IF', 'notthere', 'eth0', ''); ERROR: system "notthere" does not exist insert into IFace values ('IF', 'orion', 'ethernet_interface_name_too_long', ''); --- 1538,1547 ---- ERROR: illegal slotlink beginning with XX CONTEXT: PL/pgSQL function "tg_slotlink_a" line 16 at assignment insert into HSlot values ('HS', 'base.hub1', 1, ''); ! ERROR: no manual manipulation of HSlot insert into HSlot values ('HS', 'base.hub1', 20, ''); ERROR: no manual manipulation of HSlot delete from HSlot; insert into IFace values ('IF', 'notthere', 'eth0', ''); ERROR: system "notthere" does not exist insert into IFace values ('IF', 'orion', 'ethernet_interface_name_too_long', ''); ======================================================================
On 5/30/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>
> I went to test this patch and got the attached regression failures.
> Please repair and resubmit. Thanks.
>
did it. sorry for the delay, i was busy this week.
--
Atentamente,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
Attachment
Patch applied. Thanks. --------------------------------------------------------------------------- Jaime Casanova wrote: > On 5/30/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > > I went to test this patch and got the attached regression failures. > > Please repair and resubmit. Thanks. > > > > did it. sorry for the delay, i was busy this week. > > -- > Atentamente, > Jaime Casanova > > "Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs and the universe trying > to produce bigger and better idiots. > So far, the universe is winning." > Richard Cook [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +