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

Re: ECGP - varchar in struct?

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: William West <wwest(at)csc(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: ECGP - varchar in struct?
Date: 2002-08-12 11:23:41
Message-ID: 20020812112341.GB11781@credativ.de (view raw or flat)
Thread:
Lists: pgsql-interfaces
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(at)Fam-Meskes(dot)De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

In response to

pgsql-interfaces by date

Next:From: Gerhard HintermayerDate: 2002-08-12 19:56:22
Subject: Re: [INTERFACES] libpgtcl modifications
Previous:From: Michael MeskesDate: 2002-08-12 11:07:13
Subject: Re: ecpg and listen/notify

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