Re: ECPG patch 4.1, out-of-scope cursor support in native mode - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Date
Msg-id 4B5DE855.4050308@cybertec.at
Whole thread Raw
In response to Re: ECPG patch 4.1, out-of-scope cursor support in native mode  (Michael Meskes <meskes@postgresql.org>)
Responses Re: ECPG patch 4.1, out-of-scope cursor support in native mode
List pgsql-hackers
Michael Meskes írta:
> On Sun, Jan 24, 2010 at 07:25:24PM +0100, Boszormenyi Zoltan wrote:
>   
>> The problem that popped up first was that adjust_informix()
>> didn't properly deal with structs, remember? I tried some
>>     
>
> Yes, that's what made me wondering.
>
>   
>> 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
>>     
>
> Now this is what I don't get.

I may have been unclear. My first attempts at solving it
either basically bypassed adjust_informix() or tried to
unroll the structs *before* calling adjust_informix().
IIRC, your comment about that solution was something
like "unrolling should be done at only one place centrally".
Which I agreed after learning what dump_variables() and
ECPGdump_a_type() do.

>  Shouldn't this test use different functions to
> really show this problem?

I don't think so. The problem only happened in case of
cursors because this was the only case when adjust_informix()
was called and the lack of handling struct/union there
was the problem. The final "else" branch used ecpg_type_name()
which calls abort() in case of unknown types.

>  Isn't it hidden now by the new functionality of not
> spitting out ECPGget_var's?
>   

No. This problem is hidden by the fact the adjust_informix()
(now adjust_outofscope_cursor_vars()) now handles structs/unions
properly and the struct members are properly unrolled by
ECPGdump_a_type().

The "not spitting out ECPGget_var()" part is about tidying
the preprocessed C source. As I wrote previously, globals
don't need transformation and nor the locals in case the
OPEN/FETCH statements are in the same function as DECLARE.

But considering all the above, we might not need the new
compat_informix/struct.pgc regression test. I think it was tested
already in e.g. preproc/array_of_struct.pgc and preproc/type.pgc
and the new feature (if accepted) is a unified one, it would show
the problem for native mode as well.

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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Clustering Docs WAS: Mammoth in Core?
Next
From: Josh Berkus
Date:
Subject: Re: handling contrib directories as modules not shared libraries