pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedecpg idea
6+ messages / 3 participants
[nested] [flat]
* ecpg idea
@ 1999-02-20 18:07 Michael Meskes <Michael_Meskes@topmail.de>
0 siblings, 2 replies; 6+ messages in thread
From: Michael Meskes @ 1999-02-20 18:07 UTC (permalink / raw)
To: pgsql-interfaces
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!
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] ecpg idea
@ 1999-02-20 18:37 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Michael Meskes <Michael_Meskes@topmail.de>
1 sibling, 1 reply; 6+ messages in thread
From: Thomas G. Lockhart @ 1999-02-20 18:37 UTC (permalink / raw)
To: Michael Meskes <Michael_Meskes@topmail.de>; +Cc: pgsql-interfaces
> ... 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] ecpg idea
@ 1999-02-20 18:45 James Thompson <jamest@math.ksu.edu>
parent: Michael Meskes <Michael_Meskes@topmail.de>
1 sibling, 1 reply; 6+ messages in thread
From: James Thompson @ 1999-02-20 18:45 UTC (permalink / raw)
To: Michael Meskes <Michael_Meskes@topmail.de>; +Cc: pgsql-interfaces
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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] ecpg idea
@ 1999-02-20 18:56 James Thompson <jamest@math.ksu.edu>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 6+ messages in thread
From: James Thompson @ 1999-02-20 18:56 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Michael Meskes <Michael_Meskes@topmail.de>; pgsql-interfaces
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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] ecpg idea
@ 1999-02-21 11:53 Michael Meskes <Michael_Meskes@topmail.de>
parent: James Thompson <jamest@math.ksu.edu>
0 siblings, 0 replies; 6+ messages in thread
From: Michael Meskes @ 1999-02-21 11:53 UTC (permalink / raw)
To: pgsql-interfaces
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!
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] ecpg idea
@ 1999-02-21 11:54 Michael Meskes <Michael_Meskes@topmail.de>
parent: James Thompson <jamest@math.ksu.edu>
0 siblings, 0 replies; 6+ messages in thread
From: Michael Meskes @ 1999-02-21 11:54 UTC (permalink / raw)
To: pgsql-interfaces
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!
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~1999-02-21 11:54 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-02-20 18:07 ecpg idea Michael Meskes <Michael_Meskes@topmail.de>
1999-02-20 18:37 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1999-02-20 18:56 ` James Thompson <jamest@math.ksu.edu>
1999-02-21 11:54 ` Michael Meskes <Michael_Meskes@topmail.de>
1999-02-20 18:45 ` James Thompson <jamest@math.ksu.edu>
1999-02-21 11:53 ` Michael Meskes <Michael_Meskes@topmail.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox