| From: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, anzai(at)sraoss(dot)co(dot)jp, nagata(at)sraoss(dot)co(dot)jp |
| Subject: | Re: 64-bit API for large object |
| Date: | 2012-09-21 15:46:23 |
| Message-ID: | CADyhKSU_w1aXTAXMD_n6b9BuYKbBc5CyTQjbLrYeS0NddjfTvA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2012/9/21 Tatsuo Ishii <ishii(at)postgresql(dot)org>:
>> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>>> My preference is nothing are changed both pg_getmsgint64() of the backend
>>> and routines under PQfn() of the libpq. Isn't it unavailable to deliver int64-
>>> value "after" the endian translation on the caller side?
>>
>> Right. If we had to change anything on the backend side, it would mean
>> we had a wire protocol change, which is even less acceptable than a
>> libpq ABI change.
>
> The patch does not touch pg_getmsgint64() and I don't think we are not
> going have a wire protocol change.
>
It's also uncertain what portion does Tom said "right" for...
What I pointed out is this patch adds a special case handling on pqFunctionCall3
of libpq to fetch 64bit-integer from PQArgBlock->u.ptr and adjust endian orders.
It is never the topic on backend side.
It is not a technical problem, but I feel a bit strange coding style.
So, I don't want to against it so much.
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)?
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Karl O. Pinc | 2012-09-21 15:54:05 | Re: Suggestion for --truncate-tables to pg_restore |
| Previous Message | Tatsuo Ishii | 2012-09-21 15:24:40 | Re: 64-bit API for large object |