Michael Meskes wrote:
> > Actually I'm looking for a dynamic length array of dynamically allocated
> > strings. (Sorry for my English, in German it's [beliebig viele Strings von
> > beliebiger Länge] to make it clear to you?).
>
> Sure. That's the exact problem because this is not a two dimensional array
> of characters but an array of pointers.
right. I'll try to implement it (since this looks like the most promising way to
me). And I would love to have this functionality in 7.2, fast.
So char **var = NULL;
get's into var[0]=result1, ... var[N-1]=resultN, var[N]=NULL
internally: var[0]= ((char*) &var[N+1]), var[1]= ((char*) &var[N+1])+(strlen(var[0])+1)
so the memory to allocate is: N+1*sizeof(char*) + Sum(strlen(resultn)+1).
And if you have any porting doubts about this proposal please tell me. I don't
have any, it's pure C. You'd have to cast your malloc result to char** anyway and
adding some extra space after the array doesn't hurt.
afterwards free(var) is all you need !
> > > exec sql type str is varchar[8];
> > > str *var=NULL;
> >
> > Shudder. There should be a decent syntax to specify this. If anyone ever
> > needs this functionality!!!
>
> You're free to add this. It's not trivial though.
Not yet.
> > Propose _if_ ever needed:
> > What about using a different varchar type e.g. [struct varchar_vca { int
> > len; char *arr; }] which corresponds to varchar or varchar[] in the
> > parser. But the user should remember to free it afterwards. Sadly we can't
> > default to C++ (destructors).
>
> How should that work? The use only defines a variable as varchar. The rest
> is doen by ecpg. In fact I would prefer if the user does not have to use
> var.arr to access the string but we could find a way to make this completely
> transparent.
I'll take a loom into the standard. Though I don't know when I'll find the time.
> > At first embedded SQL was meant to be portable. And we successfully ported
> > our LNX and Adabas D programs to Postgres. And we share applications between
> > Oracle and Postgres databases.
> > ...
That was just self pitying. And sarcasm about unimplemented or simply never
in-documentation-mentioned standards. [sidekick to big commercial database]
> Don't get me wrong. I did not mean portable to other DBMSs but portable to
> other OSs and C compiler. If it works on all platforms PostgreSQL works on,
> I'm satisfied.
Me too. But then I could have chosen PQ++ from the beginning.
Christof
PS: Does anybody have interest in SQLDA?
