Follow-up to a recent mail question and s.to.rast problem:
I could not convert to pixels sites list if they had third column starting with
'@' which is a string attribute sign. Then, I found out that sites produced
by d.site.pg always had 'string' third column, even if fields of types int or
float were selected from table as category fields. To make s.to.rast conversion
possible, we had to change all '@' by '#' in site_lists.
To somehow avoid this, I've added field type recognition to d.site.pg based on the
values returned by PQftype and described in pg_type.h (which is not present in
post-install postgres header directory), constructing different type site lists,
at the CVS.
--alex
Alex Shevlakov wrote:
I could not convert to pixels sites list if they had third column
starting with '@' which is a string attribute sign. Then, I found
out that sites produced by d.site.pg always had 'string' third
column, even if fields of types int or float were selected from
table as category fields. To make s.to.rast conversion possible, we
had to change all '@' by '#' in site_lists.
To somehow avoid this, I've added field type recognition to
d.site.pg based on the values returned by PQftype and described in
pg_type.h (which is not present in post-install postgres header
directory), constructing different type site lists, at the CVS.
This concerns version 1.8 of d.site.pg/runInfxFile.c, right?
Are you saying that your PostgreSQL installation doesn't have
<catalog/pg_type.h>? If so, do you have any idea whether this is
likely to be a common problem?
Using integer constants in the source code should be avoided if at all
possible. If it's unreasonable to rely upon the presence of
<catalog/pg_type.h>, the various *OID macros should be #define'd
locally.
--
Glynn Clements <glynn.clements@virgin.net>
On Sat, Mar 09, 2002 at 09:12:38PM +0000, Glynn Clements wrote:
Are you saying that your PostgreSQL installation doesn't have
<catalog/pg_type.h>? If so, do you have any idea whether this is
likely to be a common problem?
I compiled 7.1.3 and 7.2 - it's not there after make install.
Using integer constants in the source code should be avoided if at all
possible. If it's unreasonable to rely upon the presence of
<catalog/pg_type.h>, the various *OID macros should be #define'd
locally.
Such like #define TXTOID 25 , and then use TXTOID IN case's clause. If
I got you right.
Besides, the 7.2 Postgres has changed structure of header directory, they have moved postgres_fe,h and c.h to another directory (/usr/local/pgsql/include/internal), so the ./configure would need know this to find the headers.
--alex