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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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!
From | Date | Subject | |
---|---|---|---|
Next Message | Gerhard Hintermayer | 2002-08-12 19:56:22 | Re: [INTERFACES] libpgtcl modifications |
Previous Message | Michael Meskes | 2002-08-12 11:07:13 | Re: ecpg and listen/notify |