CommitFest 2009-09, two weeks on
in [PgSql]
|
From: Boszormenyi Zoltan on 12 Nov 2009 05:12 Alvaro Herrera �rta: > Boszormenyi Zoltan escribi�: > > >> I have split up (and cleaned up a little) the dynamic >> cursorname patch into smaller logical, easier-to-review >> pieces. Descriptions below. >> >> 1) 1a-unified-optfromin-fetch-ctxdiff.patch >> >> ecpg supports optional FROM/IN in FETCH and >> MOVE statements (mainly because it's required by >> Informix-compatibility). Unify core and ecpg grammar >> as per Tom Lane's suggestion. >> > > I have applied this patch after some tinkering. I mainly added support > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in > name" in ecpg.addons which apparently you forgot. > Thanks. Your fix is correct if this patch is considered standalone. This means I have to re-post the later patches to fix the reject this fix causes in them. Best regards, Zolt�n B�sz�rm�nyi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zolt�n B�sz�rm�nyi Cybertec Sch�nig & Sch�nig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 12 Nov 2009 05:17 Alvaro Herrera �rta: > Boszormenyi Zoltan escribi�: > > >> 2) 1b-cursor_name-ctxdiff.patch >> >> "name" -> "cursor_name" transition in core grammar >> and ecpg grammar. Currently it does nothing, it's a >> preparation phase. Depends on patch 1. >> > > Applied this part too. > > I cannot apply the other ones -- they belong to the ECPG maintainer. I > hope I cleared his road a bit. > Thanks and best regards, Zolt�n B�sz�rm�nyi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zolt�n B�sz�rm�nyi Cybertec Sch�nig & Sch�nig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 12 Nov 2009 14:49 Boszormenyi Zoltan escribi�: > Alvaro Herrera �rta: > > I have applied this patch after some tinkering. I mainly added support > > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in > > name" in ecpg.addons which apparently you forgot. > > Thanks. Your fix is correct if this patch is considered > standalone. This means I have to re-post the later > patches to fix the reject this fix causes in them. Yeah. BTW I don't think the rest of the pieces in this series make sense to apply separately, because they don't do anything useful by themselves (one of them introduces an unused function, what good is in that?). I think they should be submitted as a single patch. If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 Nov 2009 15:07 On Thu, Nov 12, 2009 at 2:49 PM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Boszormenyi Zoltan escribió: >> Alvaro Herrera írta: > >> > I have applied this patch after some tinkering. I mainly added support >> > for "fetch_args: FORWARD opt_from_in name" and "BACKWARD opt_from_in >> > name" in ecpg.addons which apparently you forgot. >> >> Thanks. Your fix is correct if this patch is considered >> standalone. This means I have to re-post the later >> patches to fix the reject this fix causes in them. > > Yeah. BTW I don't think the rest of the pieces in this series make > sense to apply separately, because they don't do anything useful by > themselves (one of them introduces an unused function, what good is in > that?). I think they should be submitted as a single patch. > > If you want to submit patches in a series like this one, they need to be > considered standalone, I think. The Linux kernel devs work differently > than us here. Zoltan broke them up because Michael asked him to do so. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Michael Meskes on 13 Nov 2009 02:06
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote: > > If you want to submit patches in a series like this one, they need to be > > considered standalone, I think. The Linux kernel devs work differently > > than us here. > > Zoltan broke them up because Michael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: meskes(a)jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |