Re: pg_dump and large files - is this a problem?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_dump and large files - is this a problem?
Дата
Msg-id 200210221600.g9MG01129921@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump and large files - is this a problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump and large files - is this a problem?  (Philip Warner <pjw@rhyme.com.au>)
Re: pg_dump and large files - is this a problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > None, but it will be compatible with itself (the most we can hope for), and 
> > will work even if shifting is not supported for off_t (how likely is 
> > that?). I agree shift is definitely the way to go if it works on arbitrary 
> > data - ie. it does not rely on off_t being an integer. Can I shift a struct?
> 
> You can't.  If there are any platforms where in fact off_t isn't an
> arithmetic type, then shifting code would break there.  I am not sure
> there are any; can anyone provide a counterexample?
> 
> It would be simple enough to add a configure test to see whether off_t
> is arithmetic (just try to compile "off_t x; x <<= 8;").  How about
>     #ifdef OFF_T_IS_ARITHMETIC_TYPE
>         // cross-platform compatible
>         use shifting method
>     #else
>         // not cross-platform compatible
>         read or write bytes of struct in storage order
>     #endif

It is my understanding that off_t is an integral type and fpos_t is
perhaps a struct.  My fgetpos manual page says:
    The fgetpos() and fsetpos() functions are alternate interfaces equivalent    to ftell() and fseek() (with whence
setto SEEK_SET ), setting and stor-    ing the current value of the file offset into or from the object refer-    enced
bypos. On some (non-UNIX) systems an ``fpos_t'' object may be a    complex object and these routines may be the only
wayto portably reposi-    tion a text stream.
 

I poked around and found this Usenet posting:

http://groups.google.com/groups?q=C+off_t+standard+integral&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=E958tG.8tH%40root.co.uk&rnum=1

stating that while off_t must be arithmetic, it doesn't have to be
integral, meaning it could be float or double, which can't be shifted.

However, since we don't know if we support any non-integral off_t
platforms, and because a configure test would require us to have two
code paths for with/without integral off_t, I suggest we apply my
version of Philip's patch and let's see if everyone can compile it
cleanly.  It does have the advantage of being more portable on systems
that do have integral off_t, which I think is most/all of our supported
platforms.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Igor Georgiev"
Дата:
Сообщение: Re: Security question : Database access control
Следующее
От: Philip Warner
Дата:
Сообщение: Re: pg_dump and large files - is this a problem?