>> 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
