Обсуждение: ecpg idea

James just asked me about a new feature in ecpg that I certainly not heard
about yet. However, I think it is a good idea.

Let's say we have the following statement:

exec sql select name into :stringvar from address;

Then stringvar has to be a variable with enough room to store the string. In
contrast to Oracle we allow stringvar to be either an array of char or a
pointer (and the varchar alternatives). However, if you provide a char * you
have to make sure it has memory allocated yourself. James now asked me to to
the correct malloc() inside libecpg if that poointer is NULL.

I never heard about a feature like this on other DBMS but I like the idea.
It should be pretty easy to implement too. Unless it is strictly against
standard I would like to implement it.

Comments anyone?

Michael
--
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net          | Use PostgreSQL!

> ... if you provide a char * you have to make sure it has memory
> allocated yourself. James now asked me to do the correct malloc()
> inside libecpg if that poointer is NULL.
> I never heard about a feature like this on other DBMS but I like the
> idea. It should be pretty easy to implement too. Unless it is strictly
> against standard I would like to implement it.
> Comments anyone?

How do you get back the handle for the newly malloc'd storage?

                     - Tom

On Sat, 20 Feb 1999, Michael Meskes wrote:

>
> I never heard about a feature like this on other DBMS but I like the idea.
> It should be pretty easy to implement too. Unless it is strictly against
> standard I would like to implement it.
>
> Comments anyone?

You know you have my vote! :-)

I'll retract my previous private statement about compatibility with Oracle
being important.  After thinking about it some more I'd much rather have a
superiour free product than compatiblility with a comercial product.

The only issue I can forsee is when virtual memory is exhausted, would
this require additional error code defined that would violate some sql
standard?  And would a NULL pointer on return siginfy a null column value
in the table or a failed malloc?

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas
State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

On Sat, 20 Feb 1999, Thomas G. Lockhart wrote:

> > ... if you provide a char * you have to make sure it has memory
> > allocated yourself. James now asked me to do the correct malloc()
> > inside libecpg if that poointer is NULL.
> > I never heard about a feature like this on other DBMS but I like the
> > idea. It should be pretty easy to implement too. Unless it is strictly
> > against standard I would like to implement it.
> > Comments anyone?
>
> How do you get back the handle for the newly malloc'd storage?
>

I'm not sure I understand.  Are your talking about the pointer value?
This was my original idea converted into code.  I was hoping to reduce the
amount of possible buffer overflows due to field size changes in a
database table, plus reduce client code maintenance.

exec sql begin declare
  char *name;
exec sql end declare

name = NULL;

exec sql select first_name
      into :name
      from customer;

if (name){
printf("The value is %s",name);
free(name);
}

If this doesn't fly is there a way to get table field lengths at run time.
I just don't like hard coded array sizes linked to table fields.  I'd
rather malloc the memory prior to the fetch.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson    138 Cardwell Hall  Manhattan, Ks   66506    785-532-0561
Kansas State University                          Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

On Sat, Feb 20, 1999 at 12:45:27PM -0600, James Thompson wrote:
> The only issue I can forsee is when virtual memory is exhausted, would
> this require additional error code defined that would violate some sql

I don't see that. There is already an OUT_OF_MEMORY error message.

> standard?  And would a NULL pointer on return siginfy a null column value
> in the table or a failed malloc?

A failed malloc. Null values are only transfered via indicators.

Michael

--
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net          | Use PostgreSQL!

On Sat, Feb 20, 1999 at 12:56:28PM -0600, James Thompson wrote:
> I just don't like hard coded array sizes linked to table fields.  I'd
> rather malloc the memory prior to the fetch.

Hard coded array sizes have one huge advantage: libecpg will know how many
bytes fit in. Thus there won't be a buffer overflow.

Michael
--
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net          | Use PostgreSQL!