Re: ECGP - varchar in struct?

>> As a PostgreSQL 'newbie', I am not sure if it is more
>> work to fix ecpg or to re-write how the application
>> does things. I see it is a 'yacc' unit that handles the
>> re-writing that ecpg now does, but I do not know
>> 'yacc-ese' and do not know what else would be involved
>> to fix ecpg to work like PRO-C?

> Yes, it's quite some work. :-) But if you volunteer I gladly accept
> patches. :-)

The 'encapsulated C' approach would require few changes to
Pro-C based application, and would make it easier to support
both Oracle and PostgreSQL from the same code-base, if ecpg
had a capabilities closer to Pro-C's.

But I am leery of the time it would take for me to continue with
that more general and portable approach (first upgrade ecpg and
then port the application) ... so I have sort of decided to convert
to using the libpq (or maybe libpqeasy + libpq) instead ... at
least then it is only one project (albeit much bigger than at
first expected).

Perhaps later, when I have mastered the libpq interface,
I'll reconsider taking you up on that, since the 'encapsulated'
approach really would be better from a maintenance point of view :-)

>> - Did I miss something here?

> Yes, at first you can list you struct definition inside the declare
> section and it will work nicely.

I need for the struct to define a shape and to be able to
*separately* instantiate instances (or arrays-of-instances)
of that shape.

As I understand it, a DECLARE section will instantiate an
instance of the struct each time I INCLUDE it in a compile unit,
and I am not sure how I would declare a multiple-rows array?

To clarify what I am faced with:

The existing application has many different structs, each of
which has members for the columns affected by any of a
number of different realtime message-driven update accesses.

That is, there are a couple of dozen different messages, each
needing to revise different columns of the tables defined
(one of which has in excess of 60 columns). There are also
'update all' messages that need to INSERT or UPDATE into *all*
columns of the 60+ columns table.

Each message is backed by a struct that has storage shapes
for the column(s) to be updated by that message. The
functions that perform message data-to-struct (or
data-from-struct) operations are in different compile
units than are the functions that issue the SQL operations
that exchange data with the database.

The application currently does pass-by-reference operations
among many functions across many separate compile units. Of
course, every compile unit having to DECLARE the struct will
give each compile unit its own *instance* of the struct and
won't allow the application to do the SQL to load/ unload
the struct from/to the database in one function in one compile
unit and then pass by reference to/ from other functions in
other compile units (as the application currently does).

In addition, the application processes some messages that work with
many rows from a given table all at once. Being unable to separate 'row
shapes' (struct layouts) from instantiation thereof (DECLARE thereof)
appears
to make it difficult or impossible to instantiate front-end space for
arrays-of-rows.

It also appears to make it impossible to have ecpg issue SELECTS/ INSERTS/
UPDATES that affect many rows as well as columns with each front-end to
back-end SQL exchange (each EXEC SQL) ... something that the present
application does a *lot* of and that - at least with Oracle - gives an
order of
magnitude performance improvement.

It appears to me that the libpq layer front-end to back-end interface
is able to pass an open-ended number of columns and rows per PQexec()
call ... that the problem would be a vectoring/ mapping definition capable
of
properly delivering PQgetvalue() returns into stuct members.

That is why, unless I am still missing something, I am inclined to convert
to
a direct-to-libpq interface (or maybe a hybrid of libpgeasy plus libpq).
Does
that seem reasonable, given the present organization of the application?