Date: Mon, 12 Aug 2002 13:23:41 +0200
From: Michael Meskes <meskes@postgresql.org>
To: William West <wwest@csc.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: ECGP - varchar in struct?
Message-ID: <20020812112341.GB11781@credativ.de>
Mail-Followup-To: William West <wwest@csc.com>,
 pgsql-interfaces@postgresql.org
References: <OF4448F465.F8B0E353-ON85256C12.00687BCF@com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF4448F465.F8B0E353-ON85256C12.00687BCF@com>
User-Agent: Mutt/1.4i

On Sun, Aug 11, 2002 at 05:14:07PM -0400, William West wrote:
> 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 moving to ECPG's encapsulated approach does not prevent the app from
running under Pro*C, i.e. Pro*C can also work with everything listed
inside the declare section etc.

> 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).

This certainly will be much more time to port the app. If you have a
Pro*C app, porting it to ECPG will almost definitely be less work than
proting to libpq.

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

But you can add the definition for each instance. Yes, C doesn't require
this, but it does not forbid it either. Also you can use a typedef to
define the struct so ecpg does the job of adding the definition.

> As I understand it, a DECLARE section will instantiate an
> instance of the struct each time I INCLUDE it in a compile unit,

What I mean is instaed of

struct foo {...};

struct foo a;
struct foo b;

you can use

exec sql begin declare section;
struct foo {...} a;
exec sql end declare section;

exec sql begin declare section;
struct foo {...} b;
exec sql end declare section;

or instead

exec sql typedef sf struct foo {...};

exec sql begin declare section;
sf a;
exec sql end declare section;

exec sql begin declare section;
sf b;
exec sql end declare section;

> and I am not sure how I would declare a multiple-rows array?

I'm not sure what you mean with this.

Also I have to admit that I didn't completely understand your mail in
terms of seeing the problem that you cannot solve with ecpg. Maybe a
code example would help me understand it better.

> 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.

Once again I do not understand that. Do you mean for instance one select
that reads several tuples at the same time?

> 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.

But that's exactly what ecpg does. It just encapsulates the libpq calls.

It seems I did not fully understand your question nor answer it
accordingly. :-)

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!