Re: ECGP - varchar in struct?
От | Michael Meskes |
---|---|
Тема | Re: ECGP - varchar in struct? |
Дата | |
Msg-id | 20020812112341.GB11781@credativ.de обсуждение исходный текст |
Ответ на | Re: ECGP - varchar in struct? ("William West" <wwest@csc.com>) |
Список | 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@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
В списке pgsql-interfaces по дате отправления: