Re: ECPG patch 4.1, out-of-scope cursor support in native mode

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
where the 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/