[GRASS5] GRASS 5.1: HAVE_POSTGRES[_H] ?

GRASS GRASS developer
1

Hi,

the recent updates to the configure[.in] of 5.1 have
eliminated HAVE_POSTGRES. At time there is only
HAVE_POSTGRES_H supported:

include/config.h
/* define if postgres exists */
/* #undef HAVE_POSTGRES */
#define HAVE_POSTGRES_H 1

Question for Radim and me is if the need both HAVE_POSTGRES and
HAVE_POSTGRES_H or not? If not, as configure[.in] now suggests
we had to update all the spreaded HAVE_POSTGRES in 5.1 code to
HAVE_POSTGRES_H. No problem of course, but we are not sure what's
correct.

(so at time the POSTGRES cannot be properly enabled)

Thanks for comments,

Markus

2

Markus Neteler wrote:

the recent updates to the configure[.in] of 5.1 have
eliminated HAVE_POSTGRES. At time there is only
HAVE_POSTGRES_H supported:

include/config.h
/* define if postgres exists */
/* #undef HAVE_POSTGRES */
#define HAVE_POSTGRES_H 1

Question for Radim and me is if the need both HAVE_POSTGRES and
HAVE_POSTGRES_H or not? If not, as configure[.in] now suggests
we had to update all the spreaded HAVE_POSTGRES in 5.1 code to
HAVE_POSTGRES_H. No problem of course, but we are not sure what's
correct.

I suspect that both are necessary.

HAVE_POSTGRES_H indicates that the header file <postgres.h> was found;
older versions of PostgreSQL have <postgres_fe.h> instead (although
config.h.in doesn't include an entry for HAVE_POSTGRES_FE_H).

Note that GRASS probably shouldn't be using either of these headers;
they concern server internals and, AFAICT, are only meant for use by
extensions to the server. Clients should normally only need
<libpq-fe.h>. In 5.0.0, those headers are only used by g.column.pg to
obtain the value of VARHDRSZ (and that dependendency has been removed
from the CVS head).

Presumably HAVE_POSTGRES was meant to reflect whether PostgreSQL
support was enabled (i.e. --with-postgres, which is the default). In
which case, I appear to have overlooked it when I updated
configure[.in].

--
Glynn Clements <glynn.clements@virgin.net>

3

On Thu, Nov 28, 2002 at 12:23:42PM +0000, Glynn Clements wrote:
[...]

> Question for Radim and me is if the need both HAVE_POSTGRES and
> HAVE_POSTGRES_H or not? If not, as configure[.in] now suggests
> we had to update all the spreaded HAVE_POSTGRES in 5.1 code to
> HAVE_POSTGRES_H. No problem of course, but we are not sure what's
> correct.

I suspect that both are necessary.

HAVE_POSTGRES_H indicates that the header file <postgres.h> was found;
older versions of PostgreSQL have <postgres_fe.h> instead (although
config.h.in doesn't include an entry for HAVE_POSTGRES_FE_H).

Note that GRASS probably shouldn't be using either of these headers;
they concern server internals and, AFAICT, are only meant for use by
extensions to the server. Clients should normally only need
<libpq-fe.h>. In 5.0.0, those headers are only used by g.column.pg to
obtain the value of VARHDRSZ (and that dependendency has been removed
from the CVS head).

A quick search shows that 5.1 only uses the libpq-fe.h.

find . -type f -name "*.[ch]" -exec grep -l postgres {} \;
./include/config.h
--> not relevant

find . -type f -name "*.[ch]" -exec grep -l libpq-fe.h {} \;
./db/drivers/postgres/globals.h
./db/pg.in.dbf/pgdump.c
./include/vect/dig_structs.h
./lib/vector/Vlib/open_post.c

-> 5.1 is fine.

Presumably HAVE_POSTGRES was meant to reflect whether PostgreSQL
support was enabled (i.e. --with-postgres, which is the default). In
which case, I appear to have overlooked it when I updated
configure[.in].

Thanks for the update.

Markus