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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Giles Lean <giles(at)nemeton(dot)com(dot)au>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump and large files - is this a problem?
Date: 2002-10-21 14:16:11
Message-ID: 17007.1035209771@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> then checking the first byte? This should give me the endianness, and makes
> a non-destructive write (not sure it it's important). Currently the
> commonly used code does not rely on off_t arithmetic, so if possible I'd
> like to avoid shift. Does that sound reasonable? Or overly cautious?

I think it's pointless. Let's assume off_t is not an arithmetic type
but some weird struct dreamed up by a crazed kernel hacker. What are
the odds that dumping the bytes in it, in either order, will produce
something that's compatible with any other platform? There could be
padding, or the fields might be in an order that doesn't match the
byte order within the fields, or something else.

The shift method requires *no* directly endian-dependent code,
and I think it will work on any platform where you have any hope of
portability anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-21 14:42:20 Re: ECPG and bison
Previous Message Philip Warner 2002-10-21 14:10:22 Re: pg_dump and large files - is this a problem?