Re: ECPG patch 4.1, out-of-scope cursor support in native mode
От | Boszormenyi Zoltan |
---|---|
Тема | Re: ECPG patch 4.1, out-of-scope cursor support in native mode |
Дата | |
Msg-id | 4B5C9094.6010307@cybertec.at обсуждение исходный текст |
Ответ на | Re: ECPG patch 4.1, out-of-scope cursor support in native mode (Michael Meskes <meskes@postgresql.org>) |
Ответы |
Re: ECPG patch 4.1, out-of-scope cursor support in
native mode
(Michael Meskes <meskes@postgresql.org>)
|
Список | pgsql-hackers |
Michael Meskes írta: > On Fri, Jan 22, 2010 at 06:11:51PM +0100, Boszormenyi Zoltan wrote: > >>> Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this test case? >>> >>> >> Because there's no ECPGget_var()s emitted for >> - global variables >> - variables in the same function >> >> ECPGget_var() is only used in case the cursor declaration >> used INTO/USING and it's in a different function from >> the one where OPEN/FETCH/CLOSE reside. But this >> cannot be determined easily, e.g. short of making ECPG >> a two-pass precompiler, so ECPGset_var() is always used. >> > > This shows some well thought implementation. Thanks. But the truth is that your comment about "this adjust_informix() hack goes into native mode only over my dead body" made me come up with this change and the reasoning. :-) Thus if some code with cursors does everything in one function then only some useless ECPGset_var() calls are added by the preprocessor, making the change the least intrusive for old regression tests. > But what I was wondering about was > why this is used as test case. While I see the need to test this part of ecpg I > thought this test case was added because it showed a problem without your > changes. > The problem that popped up first was that adjust_informix() didn't properly deal with structs, remember? I tried some small changes to fix that but they turned out to be improper ones. The small changes worked for the initial problem, i.e. IIRC in some cases adjust_informix() was bypassed and the struct/union members were unrolled properly for Informix compat mode, too. The regression test "compat_informix/struct.pgc" shows this case. Then our client showed a much larger programme which actually used cursors in an event driver way. E.g. PgUp/PgDn called different functions that contained only FETCH NEXT or FETCH PRIOR. This was a curses based terminal programme and my first little patch that solved only the struct unrolling case failed in this case, because either ECPG segfaulted in adjust_informix() or the code that ECPG produced for the FETCH statements didn't have the proper output variables. This is lead to the changes in the patch, which can be summarized as: 1. track function names via the lexer (to minimize the impact of ECPGget_var(), now we can compare the function name wherethe cursor was DECLAREd and is used) 2. track type names for structs/unions to be able to emit (* ( typename *) &var) in adjust_informix(), and 3. rewriting adjust_informix() to handle struct/union The result is that cursors handling statements (OPEN/FETCH/MOVE) can now be safely put into a different function from where it was DECLAREd. And this makes possible to use ECPG in event driven code, which is a feature that I think worth considering making available in native mode, too. This is why adjust_informix() was also renamed. And while I agree with your comment about that "this can lead to dangerous programming", I think the only thing needed is to document the safety borders, not to prevent crossing them. C is about "living la vida loca". ;-) The regression test introduced (preproc/outofscope.pgc) tries to show this functionality. Currently (without the patch) this test makes ECPG abort in ecpg_type_name(). 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/
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns