From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeremy Drake <pgsql(at)jdrake(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Mark Dilger <pgsql(at)markdilger(dot)com> |
Subject: | Re: 64-bit API for large objects |
Date: | 2005-09-23 21:40:09 |
Message-ID: | 6801.1127511609@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeremy Drake <pgsql(at)jdrake(dot)com> writes:
> 2) The lo_*64, in order to be convenient from the client end, have
> functions added to libpq as the existing lo_* functions. The client side
> of libpq did not previously know anything about int64 or how to
> send/receive them. I added an include of postgres-fe.h (which according
> to the comment in that file looks like it should go there) so int64 would
> be defined,
Unfortunately that's completely unacceptable from a namespace-pollution
point of view.
The real problem here is that int64 isn't a well-defined portable
datatype, and so it's going to be very hard to export these functions in
a way that won't break on different platforms, applications compiled
with a different compiler than libpq was, etc.
For that matter, we can't even guarantee that they work at all: not all
platforms even *have* int64 types. We have so far avoided putting any
fundamental dependencies on int64 arithmetic into the system, and I'm a
bit worried that this patch will break LO support entirely on platforms
that don't have working int64 arithmetic.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-09-23 21:44:26 | Re: [COMMITTERS] pgsql: Basic documentation for ROLEs. |
Previous Message | Bruce Momjian | 2005-09-23 21:39:15 | Re: Patching dblink.c to avoid warning about open transaction |