From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Nozomi Anzai <anzai(at)sraoss(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 64-bit API for large object |
Date: | 2012-10-01 13:02:12 |
Message-ID: | 50699454.4050706@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-10-01 13:05:18 | Re: CTE optimization fence on the todo list? |
Previous Message | Peter Geoghegan | 2012-10-01 11:33:07 | Re: Hash id in pg_stat_statements |