Re: 64-bit API for large object
| От | Kohei KaiGai |
|---|---|
| Тема | Re: 64-bit API for large object |
| Дата | |
| Msg-id | CADyhKSU_w1aXTAXMD_n6b9BuYKbBc5CyTQjbLrYeS0NddjfTvA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 64-bit API for large object (Tatsuo Ishii <ishii@postgresql.org>) |
| Ответы |
Re: 64-bit API for large object
|
| Список | pgsql-hackers |
2012/9/21 Tatsuo Ishii <ishii@postgresql.org>: >> Kohei KaiGai <kaigai@kaigai.gr.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@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: