Re: SPI bug.

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

In response to

Responses

Browse pgsql-hackers by date

  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