Re: ECPG support for struct in INTO list

Michael Meskes írta:
> On Wed, Aug 05, 2009 at 04:22:53PM +0200, Boszormenyi Zoltan wrote:
>
>> If you meant like this below, then ECPG segfaults on this too:
>>
>
> Right, because arrays as as well unimplemented as are structs. I meant
> something like this;
>
> int *
> get_var(void)
> {
> EXEC SQL BEGIN DECLARE SECTION;
> static int myvar;
> EXEC SQL END DECLARE SECTION;
>
> EXEC SQL DECLARE mycur CURSOR FOR SELECT id INTO :myvar FROM a1 WHERE id = 1;
> return (&myvar);
> }
>

Which isn't exactly a good programming habit.
It can break subtly in multi-threaded code.
And you were talking about allocated variables, which,
in my book (without explicitely mentioning "statically")
boils down to malloc().

>> Attached is my modified test28.pgc. Compiling it
>> *without* -C INFORMIX makes it unusable, the variable
>> or the address where the data should be fetched into
>> doesn't even gets emitted in neither the DECLARE/OPEN
>> nor the FETCH callsites. I think this code should be valid
>> even in non-Informix-compatible mode.
>>
>
> I don't think i buy into this. The variable is out of scope at the time open is
> called. Why do you think this should work?
>

Because the allocated area, the pointer to it that's returned
from the function _is_ in scope. Possibly under a new name,
but that's why ECPG employs ECPG_informix_set_var() and
_get_var(), to make OPEN and FETCH independent of the
out of scope variables, no?

This code is not much different:

int *
get_var(void)
{
static int myvar;
return (&myvar);
}

another_func(...)
{
EXEC SQL BEGIN DECLARE SECTION;
int *myvar = get_var();
EXEC SQL END DECLARE SECTION;

EXEC SQL DECLARE mycur CURSOR FOR SELECT id INTO :myvar FROM a1 WHERE id = 1;

EXEC SQL OPEN mycur;

...
}

But it also breaks in compatibility mode, exactly because
adjust_informix() is called on it and even in-scope variables
are replaced with ECPG_informix_set_var() and _get_var() calls
and adjust_informix() is not prepared to certain types (array, struct).

And if you just consider this which doesn't break:

another_func(...)
{
EXEC SQL BEGIN DECLARE SECTION;
int myvar;
EXEC SQL END DECLARE SECTION;

EXEC SQL DECLARE mycur CURSOR FOR SELECT id INTO :myvar FROM a1 WHERE id = 1;

EXEC SQL OPEN mycur;

...
}

In the above code local, in-scope variables are also replaced
with ECPG_informix_set_var() and _get_var() calls.
Totally unnecessary, or totally necessary even in non-compatible
mode, depending on which leg I stand on. If you move the
struct/union unrolling into adjust_informix() and handle arrays,
ECPGdump_a_struct() won't be needed then.

>>> ... Just look at
>>> test/compat_informix/test_informix.pgc for a real and working example.
>>>
>>>
>> The example there is the other way around.
>> The variable, the DECLARE and FETCH commands
>> are in the outer main() function, and it calls a function called
>> openit() where the OPEN command is emitted, so that
>> example doesn't help here too much.
>>
>
> Eh, why not?

Because that example contradicts all sensible programming habits.
(Well, what is "sensible" is different between people, so don't take it
personal.)

> We're talking about a bug/missing feature in the precompiler
> itself. And the precompiler doesn't see this difference. I just pointed you to
> one working example. Anyway I attached a modified test28.pgc that should work
> in compatibility mode.
>
> Michael
>

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