From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SPI bug. |
Date: | 2005-05-02 14:59:59 |
Message-ID: | 18439.1115045999@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> Exactly. Why should a user of the SPI API be exposed to or even
> concerned with this at all? As an application programmer you couldn't
> care less. You want your app to perform equally well on all platforms
> without surprises. IMHO, PostgreSQL should make a decision whether the
> SPI functions support 32-bit or the 64-bit sizes for result sets and the
> API should reflect that choice. Having the maximum number of rows
> dependent on platform ports is a bad design.
The fact that 64-bit platforms can tackle bigger problems than 32-bit
ones is not a bug to be worked around, and so I don't see any problem
with the use of "long" for tuple counts. Furthermore, we have never
promised ABI-level compatibility across versions inside the backend,
and we are quite unlikely to make such a promise in the foreseeable
future. (Most of the time you are lucky if you get source-level
compatibility ;-).) So I can't get excited about avoiding platform
dependency in this particular tiny aspect of the API.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Held | 2005-05-02 15:00:11 | Re: [HACKERS] Increased company involvement |
Previous Message | Merlin Moncure | 2005-05-02 14:57:29 | Re: pg_locks needs a facelift |