CommitFest 2009-09, two weeks on
in [PgSql]
|
From: Boszormenyi Zoltan on 1 Oct 2009 15:05 Michael Meskes �rta: > On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote: > >> Please, accept my apologies, I only tried to express my >> frustration, this is not a good situation for either of us. >> > > Apologies accepted, email is a difficult means of communication anyway. It > leads to misunderstanding IMO. > > >> You were busy with your job and other occupations. >> We have a serious project going on that depend on >> ECPG being more compatible to Informix. >> > > Please keep in mind that the needs of your business project cannot and will not > influence the way PostgreSQL as on OSS project will work. > Yes, but technical problems and solutions do. ECPG claims to be ESQL/C compatible, but at places it's only half compatible. For our project to succeed, we need more compatibility in ECPG. It's easier to solve these problems in ECPG than to code around it in literally thousands of little programs. BTW, a thought about the comment in ecpg.header about adjust_informix(): /* Informix accepts DECLARE with variables that are out of scope when OPEN is called. * for instance you can declare variables in a function, and then subsequently use them * { * declare_vars(); * exec sql ... which uses vars declared in the above function * * This breaks standard and leads to some very dangerous programming. This comment is misleading and reflects quite a narrow POV. Not only OPEN and DECLARE may be out of scope, but FETCH and CLOSE as well. The reason why ESQL/C allows this construct is that this ultimately allows using embedded SQL in event-driven code in a straightforward way. For this purpose, native ECPG code is not usable currently, or you need programming tricks, like tracking whether the cursor is open and protecting DECLARE and OPEN under some conditional branch to avoid double open, etc. A straight DECLARE, OPEN, FETCH(s) and CLOSE series in the same function is only good for batch programming. >> Would this be accepted this way? Or the two modification washed into one? >> > > It is accepted either way. I was just pointing out that it might be easier to > review/commit at least parts of your patches if they can be applied seperately. > Okay, I will split the remaining patches into more little pieces that can reviewed more easily. Some patches will still build on earlier ones in the series, that's unavoidable. >> I thought you forgot that patch, the "please, look at that patch" >> was an (I thought) polite request, it's really two one-liners. >> > > Well, this is true as the patch was buried in the long thread containing all > the other ones. And yes, now that you brought it into my memory again, I > already committed it. Sorry for missing it. > Thank you very much for committing it. 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: Michael Meskes on 2 Oct 2009 09:37 On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote: > Yes, but technical problems and solutions do. ECPG claims > to be ESQL/C compatible, but at places it's only half compatible. Where does it claim to be fully compatible? > This comment is misleading and reflects quite a narrow POV. > Not only OPEN and DECLARE may be out of scope, > but FETCH and CLOSE as well. The reason why ESQL/C > allows this construct is that this ultimately allows using > embedded SQL in event-driven code in a straightforward way. > For this purpose, native ECPG code is not usable currently, > or you need programming tricks, like tracking whether the > cursor is open and protecting DECLARE and OPEN under > some conditional branch to avoid double open, etc. A straight > DECLARE, OPEN, FETCH(s) and CLOSE series in > the same function is only good for batch programming. Examples? 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 Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use 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
From: Boszormenyi Zoltan on 2 Oct 2009 10:27 Michael Meskes �rta: > On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote: > >> Yes, but technical problems and solutions do. ECPG claims >> to be ESQL/C compatible, but at places it's only half compatible. >> > > Where does it claim to be fully compatible? > I didn't say it claims to be fully compatible, but it's a "hint" that "ecpg -C INFORMIX[_SE]" exists. :-) >> This comment is misleading and reflects quite a narrow POV. >> Not only OPEN and DECLARE may be out of scope, >> but FETCH and CLOSE as well. The reason why ESQL/C >> allows this construct is that this ultimately allows using >> embedded SQL in event-driven code in a straightforward way. >> For this purpose, native ECPG code is not usable currently, >> or you need programming tricks, like tracking whether the >> cursor is open and protecting DECLARE and OPEN under >> some conditional branch to avoid double open, etc. A straight >> DECLARE, OPEN, FETCH(s) and CLOSE series in >> the same function is only good for batch programming. >> > > Examples? > I took my outofscope.pgc example from our "out of scope" patch and shortened it. Compare the ecpg-native and compat outputs and the esql output of the same file. The ecpg outputs are generated with 8.4.1 plus out patches added, the native output differs only from 8.3.7's ecpg in the amount of whitespaces emitted between literals. The get_record1() function can be called from a button-handler, e.g. when pressing PgDn, or similar... No tricks needed, straightforward code. 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/
From: Robert Haas on 2 Oct 2009 21:03 On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan <zb(a)cybertec.at> wrote: > Hi, > > Michael Meskes írta: >> It is accepted either way. I was just pointing out that it might be easier to >> review/commit at least parts of your patches if they can be applied seperately. >> > > 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. > > 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. > > 3) 1c-remove-var-from-list.patch > > Introduce function remove_variable_from_list(). > It is used by the dynamic cursor, SQLDA and DESCRIBE > patches for different reasons. Applicable separately. > > 4) 1d-dynamiccur-ctxdiff.patch > > The real point of the whole series in this email. > Extend "cursor_name" in the ecpg grammar to actually > accept a character variable. The cursorname-as-variable > is replaced in the final SQL script with a $0 placeholder. > Doesn't compile as-is, requires patch 5 to get the > two shift/reduce conflicts fixed. Depends on patches > 1, 2 and 3. > > 5) 1e-fix-shiftreduce-ctxdiff.patch > > De-factorize "BACKWARD opt_from_in cursor_name" > and "FORWARD opt_from_in cursor_name" out of > fetch_args and pull them up into FetchStmt in the ecpg > grammar. Depends on patch 4. > One line in parse.pl is not clear for me: > $replace_line{'fetch_args'} = 'ignore'; > The genarated preproc.y is the same with or without > this line. But as the previous version had it with > "fetch_direction", I left it in. > > 6) 1f-cursorname-in-varchar-ctxdiff.patch > > Allow that varchar can be used as cursorname as well. > Other character variable types were already supported. > Depends on patch 4. > > 7) 1g-regressiontests-ctxdiff.patch > > Introduce cursor.pgc regression test for both native > and compat mode. Depends on all patches. > > 8) 1h-fix-parse.pl-ctxdiff.patch > > Now useless patch, in the previous dynamic cursorname > patch the following scenario occured: the same rule > had both an "addon" and a "rule" extension. Without > this fix, the following code was generated in preproc.y: > ruleA: <accepted syntax> > { > <addon code block> > { > <automatic code block> > } > With the cleanup I did during this splitup, this scenario > doesn't happen, but this fix may be considered useful. > Applicable separately. > > After every patch (except 4) both the core and ecpg > "make check" are successful. It would've been nice if you'd changed the subject line before posting these. Also, please update commitfest.postgresql.org appropriately. ....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: Robert Haas on 3 Oct 2009 20:54
On Thu, Oct 1, 2009 at 7:48 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro > <itagaki.takahiro(a)oss.ntt.co.jp> wrote: >> >> Magnus Hagander <magnus(a)hagander.net> wrote: >> >>> I can certainly review the win32 encoding patch, but I was rather >>> hoping for some comments from others on if we're interested in a win32 >>> only solution, or if we want something more generic. Should we just go >>> with the win32-only one for now? >> >> Yes, because Windows is only platform that supports UTF-16 encoding natively. >> I believe my patch is the best solution for Windows even if we have another >> approach for other platforms. > > Actually, I think a better argument is that since Windows will *never* > accept UTF8 logging, and that's what most databases will be in, much > of this patch will be required anyway. So I should probably review and > get this part in while we think about other solutions *as well* for > other platforms. Given the above, it seems that perhaps we could go ahead and apply this? ....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 |