> > > The question is *which* seek APIs we need to support. Are there any > > > besides fseeko() and fgetpos()? > > > > On AIX we have > > int fseeko64 (FILE* Stream, off64_t Offset, int Whence); > > which is intended for large file access for programs that do NOT > > #define _LARGE_FILES > > > > It is functionality that is available if _LARGE_FILE_API is defined, > > which is the default if _LARGE_FILES is not defined. > > > > That would have been my preferred way of handling large files on AIX > > in the two/three? places that need it (pg_dump/restore, psql and backend COPY). > > This would have had the advantage that off_t is not 64 bit in all other places > > where it is actually not needed, no ? > > OK, I am focusing on AIX now. I don't think we can go down the road of > saying where large file support is needed or not needed. I think for > each platform either we support large files or we don't. Is there a way > to have off_t be 64 bits everywhere, and if it is, why wouldn't we just > enable that rather than poke around figuring out where it is needed?
if _LARGE_FILES is defined, off_t is 64 bits on AIX (and fseeko works). The problem with flex is, that the generated c file does #include <unistd.h> before we #include "postgres.h". In this situation _LARGE_FILES is not defined for unistd.h and unistd.h chooses to define _LARGE_FILE_API, those two are not compatible. If a general off_t of 64 bits is no performance problem, we should focus on fixing the #include <unistd.h> issue, and forget what I wanted/hinted. Peter E. has a patch for this in his pipeline. I can give it a second try tomorrow. Sorry for the late answer, I am very pressed currently :-( Andreas ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
