From: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at> |
Subject: | Re: ECPG support for struct in INTO list |
Date: | 2009-08-07 09:48:33 |
Message-ID: | 4A7BF871.5000608@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Bernd Helmle | 2009-08-07 10:08:15 | Re: mixed, named notation support |
Previous Message | Greg Stark | 2009-08-07 09:33:33 | Re: Table and Index compression |