Re: ECPG support for struct in INTO list - Mailing list pgsql-hackers

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/