On Mon, 2002-08-12 at 09:39, Andrew Sullivan wrote: > On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote: > > > I'm actually amazed that postgres isn't already using large file > > support. Especially for tools like dump. > > Except it would only cause confusion if you ran such a program on a > system that didn't itself have largefile support. Better to make the > admin turn all these things on on purpose, until everyone is running > 64 bit systems everywhere.
If by "turn...on", you mean recompile, that's a horrible idea IMO. Besides, you're expecting that an admin is going to know that he even needs to recompile to obtain this feature let alone that he'd interested in compiling his own installation. Whereas, more then likely he'll know off hand (or can easily find out) if his FS/system supports large files (>32 bit sizes). Seems like, systems which can natively support this feature should have it enabled by default. It's a different issue if an admin attempts to create files larger than what his system and/or FS can support. I guess what I'm trying to say here is, it's moving the problem from being a postgres specific issue (not compiled in -- having to recompile and install and not knowing if it's (dis)enabled) to a general body of knowledge (does my system support such-n-such capabilities). If a recompile time is still much preferred by the core developers, perhaps a log entry can be created which at least denotes the current status of such a feature when a compile time option is required. Simply having an entry of, "LOG: LARGE FILE SUPPORT (DIS)ENABLED (64-bit file sizes)", etc...things along those lines. Of course, having a "--enable-large-files" would be nice too. This would seemingly make sense in other contexts too. Imagine a back-end compiled with large file support and someone else using fe tools which does not support it. How are they going to know if their fe/be supports this feature unless we let them know? Greg
signature.asc
Description: This is a digitally signed message part