> 2012/9/21 Tatsuo Ishii <is...@postgresql.org>: >>>>>> I thought pgPutInt64() takes care of endianness. No? >>>>>> >>>>> It works inside of the PGfn(), when isint = 1 towards pointer data type. >>>>> In my sense, it is a bit problem specific solution. >>>>> >>>>> So, I'd like to see other person's opinion here. >>>> >>>> I think we cannot change this because we want to keep the counter part >>>> backend side function pq_getmsgint64() as it is (the function is not >>>> part of the patch). >>>> >>> My opinion is lo_lseek64() and lo_tell64() should handle endian translation >>> prior and next to PQfn() invocation; to avoid the int64 specific >>> case-handling >>> inside of PQfn() that can be called by other applications. >>> >>> Am I missing something? >> >> So what do you want to do with pq_getmsgint64()? It exactly does the >> same thing as pqPutInt64(), just in opposit direction. Do you want to >> change pq_getmsgint64()? Or add new function in backend? >> > 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?
I am confused. >>> My opinion is lo_lseek64() and lo_tell64() should handle endian translation >>> prior and next to PQfn() invocation; to avoid the int64 specific >>> case-handling >>> inside of PQfn() that can be called by other applications. Why do we need this? If PQArgBlock.isint != 0, it treats input data as integer anyway. So I don't see any use case other than "int64 specific case-handling" if isint != 0 and len == 8. If you have other use case for isint != 0 and len == 8, please show it. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
