Horton
Menu

Re: 64-bit API for large object

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Tatsuo Ishii <ishii@postgresql.org>, pgsql-hackers@postgresql.org, anzai@sraoss.co.jp, nagata@sraoss.co.jp
Date: 2012-09-21T16:16:36Z
Lists: pgsql-hackers 
Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> Tom, could you give us a suggestion which manner is better approach; whether
> the PQfn should have responsibility for endian translation of 64bit-integer, or
> callers (lo_tell64 or lo_seek64)?

Adding anything inside pqFunctionCall is useless, unless we were to add
an int64 variant to PQArgBlock, which isn't a good idea because it will
be an ABI break.  The functions in fe-lobj.c have to set up the int64
value as if it were pass-by-reference, which means dealing with
endianness concerns there.

			regards, tom lane

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