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

On Fri, Oct 26, 2001 at 09:49:47AM +0200, Christof Petig wrote:
> I think it has never been implemented.

Yes, if my memory serves well, I wasn't sure how to implement this so it
works on all architectures.

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

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

Sure. That's why I implemented it. :-)

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

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

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

I see. Yes, that's the problem. The very same code works with all datatypes
except char *.

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

That's true. 

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

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.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!