Re: ECPG: Automatic Storage allocation for NULL-pointing output variables
От | Michael Meskes |
---|---|
Тема | Re: ECPG: Automatic Storage allocation for NULL-pointing output variables |
Дата | |
Msg-id | 20011026075930.A4120@feivel.fam-meskes.de обсуждение исходный текст |
Ответ на | ECPG: Automatic Storage allocation for NULL-pointing output variables (Christof Petig <christof@petig-baender.de>) |
Список | pgsql-interfaces |
On Wed, Oct 24, 2001 at 01:27:48PM +0200, Christof Petig wrote: > But ecpg does not accept > char **var=0; You mean the parser I guess. Well, I'm not even sure an array of strings ever has been implemented. > Is there any way to specify arbitrary strings of any length ? char *var=NULL; declares an empty pointer which is then allocated by libecpg. > The code (execute.c:435) has also support for varchar - but how to > declare such a variable length varchar? Yes, as ecpg says: ERROR: pointer to varchar are not implemented But you should be able to work around this by using something like this: exec sql type str is varchar[8]; ... str *var=NULL; ... However, I did not try this, so I'm not sure. > And the code (execute.c:432) multiplies the number of tuples with the > longest string. But how to use this code in real life? Sorry, I do not understand that. Where's the problem? The code is executed after the result has been read using libpq. So it already knows all the result strings and can calculate the longest one. > PS: I'm willing to implement char** > (allocate tuples*sizeof(char*) + sum(length(tuple[n])+1) bytes, Or as it is now tuples*sizeof(char*)*max(length(tuple[n])+1) bytes. > fill the array with pointers, > fill the space behind the array with the actual data. > This means just one free get's it all. Which indeed is important. > But this code cannot be portable!) Which is exactly the problem. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
В списке pgsql-interfaces по дате отправления: