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-05 13:04:00
Message-ID: 4A798340.6040808@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Meskes írta:
> On Wed, Aug 05, 2009 at 11:52:57AM +0200, Boszormenyi Zoltan wrote:
>
>> This means that what I did in my first patch for this
>> problem in "add_struct_to_head()" (unrolling members
>> of the struct) has to be done in adjust_informix(),
>> turning it into a recursive function.
>> I think this would be a good solution. What do you think?
>>
>
> No, this doesn't seem right. There should be no need to unroll a struct.
> Instead I would think struct support should be added to the get_var/set_var
> functions. At least that's my guess without really digging into it.
>
> Michael
>

My question is: why not unroll the struct in the preprocessor?
This adjust_informix() issue aside, if I do this in the same function:

EXEC SQL BEGIN DECLARE SECTION;
MYTYPE myvar;
MYNULLTYPE mynullvar;
EXEC SQL END DECLARE SECTION;

EXEC SQL DECLARE mycur CURSOR FOR SELECT * INTO :myvar
:mynullvar FROM a1;
EXEC SQL OPEN mycur;

EXEC SQL WHENEVER NOT FOUND DO BREAK;
while (1) {
EXEC SQL FETCH FROM mycur;
...
}

then the preprocessed code for DECLARE and FETCH look like below:

{ ECPGdo(__LINE__, 1, 1, NULL, 0, ECPGst_normal, "declare mycur
cursor for select * from a1 where id = 1", ECPGt_EOIT,
ECPGt_int,&(myvar.id),(long)1,(long)1,sizeof(int),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_char,&(myvar.t),(long)64,(long)1,(64)*sizeof(char),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_double,&(myvar.d1),(long)1,(long)1,sizeof(double),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_double,&(myvar.d2),(long)1,(long)1,sizeof(double),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_char,&(myvar.c),(long)30,(long)1,(30)*sizeof(char),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);
#line 39 "test28.pgc"

...

{ ECPGdo(__LINE__, 1, 1, NULL, 0, ECPGst_normal, "fetch from
mycur", ECPGt_EOIT,
ECPGt_int,&(myvar.id),(long)1,(long)1,sizeof(int),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_char,&(myvar.t),(long)64,(long)1,(64)*sizeof(char),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_double,&(myvar.d1),(long)1,(long)1,sizeof(double),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_double,&(myvar.d2),(long)1,(long)1,sizeof(double),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_char,&(myvar.c),(long)30,(long)1,(30)*sizeof(char),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);
#line 43 "test28.pgc"

These are done by ECPGdump_a_struct(), when the struct's members
and their type, size, etc are known. It's unrolled by the ecpg preprocessor.
Your idea about pushing struct support into set_var/get_var seems
not appropriate. With the current set_var scheme, you pass one variable's
properties. Why not keep this simplicity and unroll the struct in the
preprocessor into multiple set_var() calls for simple types?

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 Boszormenyi Zoltan 2009-08-05 13:07:04 Re: status of ECPG patches?
Previous Message Michael Meskes 2009-08-05 13:02:13 Re: status of ECPG patches?