Re: ECPG: Automatic Storage allocation for NULL-pointing

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?