Re: ECPG support for struct in INTO list

Michael Meskes írta:
> On Fri, Aug 07, 2009 at 11:48:33AM +0200, Boszormenyi Zoltan wrote:
>
>> Which isn't exactly a good programming habit.
>>
>
> I couldn't agree more.
>

:-)

>> 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.
>>
>
> Yeah, right, and you also add this hack to all applications. No.
>

What do you mean?

In the meantime, I recalled my original idea, the patch
you have already seen, where an unrolling was introduced
in "ecpg_into:" rule with a new add_struct_to_head() function.
"ecpg_into:" is a good central place where this unrolling
can be done, so:
- ECPGdump_a_struct() won't be needed, and
- adjust_informix() doesn't encounter structs or unions.
So, struct unrolling would still be done at only one place
and one problem goes away.
About the arrays, I have to think about more.

>> Because that example contradicts all sensible programming habits.
>> (Well, what is "sensible" is different between people, so don't take it
>> personal.)
>>
>
> Hey, don't blame me! Informix uses this feature to some extend, this is why it
> got implemented. If you look into the source code you will see this:
>
> * This breaks standard and leads to some very dangerous programming.
> * Since they do, we have to work around and accept their syntax as well.
> * But we will do so ONLY in Informix mode.
>

I didn't want to blame you, I just wanted to say that
from my experience, it's more common that these are
the separation blocks:
1. memory allocation
1a. DECLARE
2. OPEN/FETCH
2a. CLOSE
3. memory freeing

Point "1a" can be grouped with either "1" or "2", similarly
point "2a" can be grouped with either "2" or "3".
"Grouped" means that they are in the same function, at
the same visibility level.

It was very alien to me seeing that only OPEN was
moved out to another function in the mentioned
regression test example.

I think that the DECLARE doing this adjust_informix()
call (which should be called adjust_out_of_scope_vars() ;-) )
shouldn't be Informix-specific at all. The above separation
is natural (again, a very subjective POV), and should be
supported in native mode, too.

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/