Re: ECPG: Automatic Storage allocation for NULL-pointing output

Michael Meskes wrote:

> 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.

I think it has never been implemented.

> > Is there any way to specify arbitrary strings of any length ?

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?).

If you consider how libepcg is implemented now, if you want to avoid network
traffic (and latency) you should transfer all results at once. And you can
read these results into an array of host variables.

But if you don't know (or don't want to hard code) how many rows are possible
(maximum), you cannot use an preallocated array. With int's it's fine [int
*var=0;] but the text types are the problem.

> char *var=NULL; declares an empty pointer which is then allocated by
> libecpg.

Sorry, I need a multi string array.

> > The code (execute.c:435) has also support for varchar - but how to
> > declare such a variable length varchar?
> 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!!!

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).

> > 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.

How to declare a variable which uses this functionality?

> > 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.

Yes, but which kind of host variable do you propose to get this feature?
That's why I talked about dead code. I couldn't declare a host variable which
used this feature.

> > But this code cannot be portable!)
>
> Which is exactly the problem.

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.

But I don't remember reading anything about dynamic allocation of host
variables in the standard. And I don't believe any longer in the
meaningfullness of this standard (after I read the oracle docs about _their_
style of embedded sql).

And ... I don't believe that the standard is this clever to foresee my
proposal for this problem. So using this vital feature makes your program
non-standard.

Christof