Skip site navigation (1) Skip section navigation (2)

Re: ECGP - varchar in struct?

From: "William West" <wwest(at)csc(dot)com>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: ECGP - varchar in struct?
Date: 2002-08-28 00:11:58
Message-ID: OFFEFB5B4B.B681A4A7-ON85256C22.007ED618@com (view raw or flat)
Thread:
Lists: pgsql-interfaces
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)

Attachment: upd_tst.tar.gz
Description: application/octet-stream (757 bytes)

Responses

pgsql-interfaces by date

Next:From: chengDate: 2002-08-28 02:48:32
Subject:
Previous:From: Paul MeisenheimerDate: 2002-08-27 23:08:07
Subject: Attempt to connect to database using libpq++ PgDatabase class fails because CONNECTION_BAD

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group