Skip site navigation (1) Skip section navigation (2)

ECPG pointer vs array

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: ECPG pointer vs array
Date: 2010-03-31 08:37:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

It would be good if libecpg to support e.g. "char **strings" instead of
"char *strings[]" for preallocated strings and the array of those.
IIRC, the first version overwrote my stack in a test programme, as these
two are treated the same but they are not.

Also, as "numeric" is supposed to be allocated using PGTYPESnumeric_new(),
we would need to support array of pointers to numeric, as well as the
static array of numerics. There's no way PGTYPESnumeric_free() works
on a static array, e.g. glibc will abort the app with a debug output of
free() on
an invalid pointer. Freeing the "digit" pointer manually is ugly,
numeric has
accessor functions, after all. Not doing anything leads to a memory leak.
Somehow digitbuf_free() should be make visible outside for such static
numeric variables.

These and other types came up regarding problems with "FETCH N"
in ECPG. All boils down to the same problem: "sometype *ptr" is
not equivalent to "sometype ptr[]" if you use &ptr, which is used
by ECPG in most cases.

Best regards,
Zoltán Böszörményi

Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-03-31 08:48:45
Subject: Re: pending patch: Re: HS/SR and smart shutdown
Previous:From: Boszormenyi ZoltanDate: 2010-03-31 08:35:31
Subject: Re: Problems with variable cursorname in ecpg

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group