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

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>
Subject: Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Date: 2010-01-25 18:52:05
Message-ID: 4B5DE855.4050308@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-01-25 18:52:56 Re: handling contrib directories as modules not shared libraries
Previous Message Josh Berkus 2010-01-25 18:50:59 Re: Clustering Docs WAS: Mammoth in Core?