>> To pass 64-bit integer to PQfn, PQArgBlock is used like this: int *ptr >> is a pointer to 64-bit integer and actual data is placed somewhere >> else. There might be other way: add new member to union u to store >> 64-bit integer: >> >> typedef struct >> { >> int len; >> int isint; >> union >> { >> int *ptr; /* can't use void >> (dec compiler barfs) */ >> int integer; >> int64 bigint; /* 64-bit integer */ >> } u; >> } PQArgBlock; >> >> I'm a little bit worried about this way because PQArgBlock is a public >> interface. >> > I'm inclined to add a new field for the union; that seems to me straight > forward approach. > For example, the manner in lo_seek64() seems to me confusable. > It set 1 on "isint" field even though pointer is delivered actually. > > + argv[1].isint = 1; > + argv[1].len = 8; > + argv[1].u.ptr = (int *) &len;
I have to admit that this is confusing. However I'm worring about changing sizeof(PQArgBlock) from compatibility's point of view. Maybe I'm just a paranoia though. >> Also we add new type "pg_int64": >> >> #ifndef NO_PG_INT64 >> #define HAVE_PG_INT64 1 >> typedef long long int pg_int64; >> #endif >> >> in postgres_ext.h per suggestion from Tom Lane: >> http://archives.postgresql.org/pgsql-hackers/2005-09/msg01062.php >> > I'm uncertain about context of this discussion. > > Does it make matter if we include <stdint.h> and use int64_t instead > of the self defined data type? I think Tom's point is, there are tons of applications which define their own "int64_t" (at least in 2005). Also pg_config.h has: #define HAVE_STDINT_H 1 and this suggests that PostgreSQL adopts to platforms which does not have stdint.h. If so, we need to take care of such platforms anyway. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers