Re: ECPG support for struct in INTO list - Mailing list pgsql-hackers
From | Boszormenyi Zoltan |
---|---|
Subject | Re: ECPG support for struct in INTO list |
Date | |
Msg-id | 4A7C38EB.2010906@cybertec.at Whole thread Raw |
In response to | Re: ECPG support for struct in INTO list (Michael Meskes <meskes@postgresql.org>) |
Responses |
Re: ECPG support for struct in INTO list
|
List | 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/
pgsql-hackers by date: