To: Michael Meskes <meskes@postgresql.org>
Cc: pgsql-interfaces@postgresql.org
Message-ID: <OFFEFB5B4B.B681A4A7-ON85256C22.007ED618@com>
From: "William West" <wwest@csc.com>
Date: Tue, 27 Aug 2002 20:11:58 -0400
Subject: Re: ECGP - varchar in struct? 
MIME-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=85256C230001BF858f9e8a93df938690918c85256C230001BF85"
Content-Disposition: inline

--0__=85256C230001BF858f9e8a93df938690918c85256C230001BF85
Content-type: text/plain; charset=us-ascii


I have worked out a method to export references to
C-Variables in a DECLARE section such that I can
pass pointer-to-struct for the 'ecpg' compile unit
to other compile units that do message and
communications processing (as the original Oracle
based package now does).

I did this by writing a tool to parse the CREATE TABLE
psql SQL directives that setup the database tables,
to emit a C-Language structure definition into one
file that non-ecpg compile units can '#include', while
emitting a separate ecpg syntax DECLARE statement
into another file that the ecpg compile unit can
EXEC SQL INCLUDE; the two are guaranteed to
be synchronized with each other because they both
come from the same CREATE TABLE statement via
the tool.
====
However, I am having a problem with the SET
arguments to UPDATE.

I have a DECLARE section that looks like this:

EXEC SQL BEGIN DECLARE SECTION;

static struct hcs_status_info_dd {
     varchar   h_f242a_opsts_3c [3];
} H_hcs_status_info;

EXEC SQL END DECLARE SECTION;

which ecpg translates to:

/* exec sql begin declare section */
 static  struct hcs_status_info_dd {
       struct varchar_h_f242a_opsts_3c  { int len; char arr[ 3 ]; }
h_f242a_opsts_3c   ;
 }  H_hcs_status_info   ;
/* exec sql end declare section */

(In the real system, the structure has a much larger
number of members, because the external message
communication and processing compile units need
to access a much larger number of columns).

ecpg does all the things I wanted for SELECT, INSERT,
etc ... but I cannot get the 'SET' arguments needed for
UPDATE to work.

I have an UPDATE statement that looks like this
(again, simplified because the 'real'; system has
*many* members-of-structure needing to be SET):

EXEC SQL UPDATE hcs_status_info SET
     f242a_opsts_3c = :H_hcs_status_info.h_f242a_opsts_3c;

ecpg translates this (chopped a little to isolate
the variable references) into:

{ ECPGdo(__LINE__, NULL, "update hcs_status_info set f242a_opsts_3c  = ?
",
ECPGt_varchar,

&(H_hcs_status_info.h_f242a_opsts_3c),

3L,1L,

sizeof(struct varchar_H_hcs_status_info.h_f242a_opsts_3c),

ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_EOIT, ECPGt_EORT);}

The "&(H_hcs_status_info.h_f242a_opsts_3c)" reference is
exactly correct to get to the 'f242a_opsts_3c' column value.

But I get an error from gcc (rightly so) because it does not like
"sizeof(struct varchar_H_hcs_status_info.h_f242a_opsts_3c)"
because the whole structure is not a vachar, only the
member-of-structure is a varchar. In fact, the struct name
"varchar_H_hcs_status_info" does *not* exist, it is the struct
name "varchar_h_f242a_opsts_3c" that *does* exist.

I believe the expression (to be correct for C) would need
to read something like:

"sizeof(struct varchar_h_f242a_opsts_3c)"
         -or-
"sizeof (H_hcs_status_info.h_f242a_opsts_3c)"
        -?or?-
====
Is there any approach that can get around this?

Note that it is far too impractical to make those
varchar members separate variables, due to the need
to 'lasso' them all into a structure, so the address
of the structure can be passed around to other compile
units that do communications and message processing.
====
I have attached a tarbun that has the entire .pgc,
the '.c' file that I get from ecpg, and a makefile
file (upd_hcs_tst.m) that runs .pcg through ecpg,
and then gcc the .c file.

(See attached file: upd_tst.tar.gz)
--0__=85256C230001BF858f9e8a93df938690918c85256C230001BF85
Content-type: application/octet-stream;
	name="upd_tst.tar.gz"
Content-Disposition: attachment; filename="upd_tst.tar.gz"
Content-transfer-encoding: base64

H4sICBwEbD0CA3VwZF90c3QudGFyAO2W/2vaQBTA/dX7Kx4dDC2pJkYtretG
q6ETgrrWwqCUEC+nBtIku7u4ddL/fRdjrYu2E0a7Mt4HJOfd+3Lv3eXlJbHn
TKlwpJAVWngZdEPXm816QVeYjcPFU69l/xXGoa7Ghw3TTMeGruRrTTUFeuEV
SIR0OUBh9J0J+awc46Lw31HdhwGPKBOCeTC6A0bjCZRqlaOKXob9KlHrwykT
DOSUMwZ+SIPEYzD2AybA5Qxcz8s05ZRBzFmcWYt4qv3uQf5Dalfexawy/Zib
DfzR5iTjPIx+nxbfAuoupgI/ZGDAXrJ2d+MJ3SNBFE6gMxpMrs4WC+poZSIc
PxxHUJpFvldukTQi9oNRUPZgxCZ+CB6jQRqKYFT6UZhunAAAKRaBACFLh40t
DiH14FNQT55QCTmnjufBHJb6zW36GUvtmcvp1OXO1BnX6jXXiWIhhWMq83OV
eAkBC1uQSqjE82sw4aYF9wCb4tAi6cLnjSSkK+vxs9DbFn224aMtGyY75JjM
SXEOVntw7kUlx7G7PctxNOhd2ba2MOlKls+U8i4hH8YJfALY09RBpMaks8yP
9r60EVkln4SyZtqaYWvC/8micSmX4V30V257fafb63Tbp8P+RRYGaKDbj79M
zOp3h4/ji2G5df9wVevbMlnkTCY8BL1F7glJz/fWVZexlI5cqmUHve/OFvl8
KuHlVPmvyt/avm5ftP43n6r/utForOr/Qk7Vf9PA+v8auEFwTIrVRPDqyA+r
i/J/IOEggvWbQSF3f9dUJpTCgVKiOY2ciXgSkQLy1sid67/o//SmYaze/3pN
jQ1TVQB8/1+DnVom66vVhssvNpxZ590edKy2fXphwaXVHnb7PSWwbIOe6YJI
cfntLW60K9fmjfqKbXYr646tXmeL2916kZWRq0HndGhttB6X1lC1erlNncDx
n5uE1hv5iCMIgiAIgiAIgiAIgiAIgiAIgiDIkl+56HdNACgAAA==

--0__=85256C230001BF858f9e8a93df938690918c85256C230001BF85--