Re: SPI bug. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SPI bug.
Date
Msg-id 18439.1115045999@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI bug.  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: SPI bug.  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-hackers
Thomas Hallgren <thhal@mailblocks.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


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: pg_locks needs a facelift
Next
From: "Dave Held"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement