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.20021023123156.0281b498@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 05:37 PM 22/10/2002 -0400, Bruce Momjian wrote: >! if (ctx->hasSeek >! #if !defined(HAVE_FSEEKO) >! && sizeof(off_t) <= sizeof(long) >! #endif >! ) Just to clarify my understanding: - HAVE_FSEEKO is tested & defined in configure - If it is not defined, then all calls to fseeko will magically be translated to fseek calls, and use the 'long' parameter type. Is that right? If so, why don't we: #if defined(HAVE_FSEEKO) #define FILE_OFFSET off_t #define FSEEK fseeko #else #define FILE_OFFSET long #define FSEEK fseek #end if then replace all refs to off_t with FILE_OFFSET, and fseeko with FSEEK. Existing checks etc will then refuse to load file offsets with significant bytes after the 4th byte, we will still use fseek/o in broken OS implementations of off_t. ---------------------------------------------------------------- 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 по дате отправления: