Re: pg_dump and large files - is this a problem?
От | Philip Warner |
---|---|
Тема | Re: pg_dump and large files - is this a problem? |
Дата | |
Msg-id | 5.1.0.14.0.20021025115936.028923e8@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: pg_dump and large files - is this a problem? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: pg_dump and large files - is this a problem?
|
Список | pgsql-hackers |
At 09:38 PM 24/10/2002 -0400, Bruce Momjian wrote: >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. Rather than having a different patch file for each platform and refusing to code fseek/tell because we can't do SEEK_CUR, why not check for FSEEKO64 and revert to a simple solution: #ifdef HAVE_FSEEKO64 #define FSEEK fseeko64 #define FTELL ftello64 #define FILE_OFFSET off64_t #else #ifdef HAVE_FSEEKO #define FSEEK fseeko #define FTELL ftello #define FILE_OFFSET off_t #else #if HAVE_FSEEK_BETTER_THAN_32_BIT #define FSEEK FSEEK_BETTER_THAN_32_BIT #define FTELL FTELL_BETTER_THAN_32_BIT #define FILE_OFFSET FILE_OFFSET_BETTER_THAN_32_BIT #else #if sizeof(off_t) > sizeof(long) #define IGNORE_FSEEK #else #define FSEEK fseek #define FTELL ftell #define FILE_OFFSET long #end if... Then use a correct checkSeek which also checks IGNORE_FSEEK. AFAICT, this *will* do the job on all systems discussed. And we can certainly skip the HAVE_FSEEK_BETTER_THAN_32_BIT bit, but coding a trivial seek/tell pair for fsetpos/fgetpos is easy, even in a macro. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: