Horton
Menu

Re: 64-bit API for large object

Peter Eisentraut <peter_e@gmx.net>

View thread
From: Peter Eisentraut <peter_e@gmx.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Nozomi Anzai <anzai@sraoss.co.jp>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-10-01T13:02:12Z
Lists: pgsql-hackers 
On 9/28/12 10:35 AM, Alvaro Herrera wrote:
> Now there is one more problem in this area which is that the patch
> defined a new type pg_int64 for frontend code (postgres_ext.h).  This
> seems a bad idea to me.  We already have int64 defined in c.h.  Should
> we expose int64 to postgres_ext.h somehow?  Should we use standard-
> mandated int64_t instead?  One way would be to have a new configure
> check for int64_t, and if that type doesn't exist, then just don't
> provide the 64 bit functionality to frontend.

Or create a new type like pg_lo_off_t.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove all the special-case code for INT64_IS_BUSTED, per decision that