Re: ECPG support for struct in INTO list

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 14:23:39
Message-ID: 4A7C38EB.2010906@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-08-07 14:25:29 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Previous Message Pierre Frédéric Caillaud 2009-08-07 14:17:18 Re: Table and Index compression