Re: ecpg weird behavior
От | Michael Meskes |
---|---|
Тема | Re: ecpg weird behavior |
Дата | |
Msg-id | 20020320200351.GA14143@feivel.fam-meskes.de обсуждение исходный текст |
Ответ на | ecpg weird behavior ("Nicolas Bazin" <nbazin@ingenico.com.au>) |
Список | pgsql-interfaces |
On Tue, Mar 19, 2002 at 07:46:04PM -0800, Thomas Lockhart wrote: > No (although I was not aware that the above would work). The example > looks like > > exec sql begin declare section; > char *name_arr[10]; > exec sql end declare section; > exec sql declare names cursor for > select name from horses; > strcpy(msg, "open"); > exec sql open names; > exec sql fetch names into :name_arr; > exec sql close names; This would mean the fetch knows how many tuples to return without you telling it. How about: ... exec sql open names; exec sql fetch 10 in names into :name_arr; exec sql close names; ... The biggest plus of this way to write the statement is that it works with ecpg. :-) I just added this to my test cases. However, I didn't have to change anything in ecpg sources. > Each FETCH returns, at most, the number of rows in the array > dimension. This has to be added. In fact ECPG has to translate the simple fetch into a fetch <how_many> ... since otherwise the backend wouldn't return more than one tuple. > Fewer rows are returned in the following cases: <snip cases> > The cumulative number of rows returned can be found in the third > element > of sqlerrd in the SQLCA, called sqlerrd[2] in this guide. This works with ECPG as well. > I'm guessing that this is a relatively short hop from your existing > array capabilities, but don't how close. What do you think? Quite easy I guess. Needs to be added to the TODO list. :-) Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
В списке pgsql-interfaces по дате отправления: