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!
