Thread: structured host variable arrays within ecpg

I am porting a large C-coded application from ALLBASE SQL
(the HP-UX DBMS) to PostgreSQL. The code makes frequent use
of embedded SQL. My intention was to skip all the static stuff
and replace it by dynamic calls to libpq. So far so good, it
went pretty well and the application is running with postgres now.
But I have to face a massive lack of performance, especially on
INSERTs. I know there is lot of overhead done, if you are going
to process let say 500 insert commands. Using COPY is not really
an option. So I was trying to re-use embedded statements, but
I had to face the fact that ecpg cannot deal with structured
host variable arrays the way I expected.
Example:
EXEC SQL  INSERT INTO ASimple_Values ( Primary_Key, List_Pointer, Parameter_Name, Parameter_Code, Parameter_Value,
Source_Type
)
VALUES ( :ASimple_Values[SQL_ii].primary_key, :ASimple_Values[SQL_ii].value_list_ptr,
:ASimple_Values[SQL_ii].parameter_name,:ASimple_Values[SQL_ii].parameter_code, :ASimple_Values[SQL_ii].value,
:ASimple_Values[SQL_ii].source_type
);
ERROR: parse error, unexpected '[', expecting ')' or ',' at or near "["

I'm using 7.2.3 and I've found in 7.3 a slightly improved documentation
on ecpg, but I still cannot figure out if something like the above is
legal within 7.3.
Are there other alternatives to process inserts on a BULK INSERT basis
(that's the feature ALLBASE was offering)?
Thanks for your time.

Regards, Christoph

On Thu, 2003-02-20 at 07:32, Christoph Haller wrote:
> I am porting a large C-coded application from ALLBASE SQL
> (the HP-UX DBMS) to PostgreSQL. The code makes frequent use
> of embedded SQL. My intention was to skip all the static stuff
> and replace it by dynamic calls to libpq. So far so good, it
> went pretty well and the application is running with postgres now.
> But I have to face a massive lack of performance, especially on
> INSERTs. I know there is lot of overhead done, if you are going
> to process let say 500 insert commands. Using COPY is not really
> an option. So I was trying to re-use embedded statements, but
> I had to face the fact that ecpg cannot deal with structured
> host variable arrays the way I expected.
> Example:
> EXEC SQL  INSERT INTO ASimple_Values (
>   Primary_Key,
>   List_Pointer,
>   Parameter_Name,
>   Parameter_Code,
>   Parameter_Value,
>   Source_Type
> )
> VALUES (
>   :ASimple_Values[SQL_ii].primary_key,
>   :ASimple_Values[SQL_ii].value_list_ptr,
>   :ASimple_Values[SQL_ii].parameter_name,
>   :ASimple_Values[SQL_ii].parameter_code,
>   :ASimple_Values[SQL_ii].value,
>   :ASimple_Values[SQL_ii].source_type
> );
> ERROR: parse error, unexpected '[', expecting ')' or ',' at or near "["
>

ecpg won't parse the above structure, as you so evidently have found
out.  It requires a simple struct.  Perhaps a future version will
support arrays?  One can hope...

What you can try to do, to circumvent this, is creative use of
pointers.  Something like:
EXEC SQL BEGIN DECLARE SECTION;struct s_stuff {    int x;    char field[20];} sqlStuff;EXEC SQL END DECLARE
SECTION;typedefstruct s_stuff MyStuff; 
void update(MyStuff *stuff){    sqlStuff = *stuff;
    EXEC SQL        INSERT INTO TABLE     VALUES (sqlStuff.x, sqlStuff.field);    /* Check sqlca, etc */}

That's just a off-the-cuff thing.  What you want to do is take your
input struct and populate an sql declared struct, and insert using that.
vi and sed are really good at mass replacements, if it comes to that. ;)

ecpg handles structures fairly well, if you declare the structure inside
a DECLARE SECTION block, and use that declared struct for the SQL
operations.  There's nothing saying you can't move data around.

Hope this helps a little.  It's just from my observations working with
ecpg.  I do, however, really like embedded sql. :)

--
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...