2012/9/21 Tatsuo Ishii <is...@postgresql.org>: >> Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
