Hi,
On Tue, 9 Apr 2002 at 19:43, Thomas Lockhart wrote:
> I don't think that our code checks explicitly for a "-1" return, since
> the range is checked just before the call, but it would probably be a
> good idea if it did
Indeed.
As I noticd yesterday, glibc's mktime() has in the current snap
> > I don't think that our code checks explicitly for a "-1" return, since
> > the range is checked just before the call, but it would probably be a
> > good idea if it did
> As I noticd yesterday, glibc's mktime() has in the current snapshot
> been changed to return -1 for dates before the epoch.
> This is the bug report against glibc that prompted the change:
>
>http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=default&pr=2738
> |> Ah, but this might explain why I've always seen on my Linux box a 1
> |> second offset returned from mktime() for dates before 1970. Eve
I think the bigger problem is that once you concatenate the custom
format for multiple databases into a single file, how does pg_restore
recognize where one database stops and another starts. I think the only
solution is to put the binary dumps in separate files, perhaps like
this:
psql
"Donald A Pellegrino" <[EMAIL PROTECTED]> writes:
> This presumes however that the custom file formats output by each pg_dump
> for a database can be concatenated into a single file. Is this possible?
AFAIK none of the custom formats are amenable to that. We could imagine
giving pg_dumpall a ta
