Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net>
Cc: pgsql-ports(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!
Date: 2000-06-26 03:31:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-ports
Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net> writes:
> 	Ok, the above patch does indeed solve the problem. And this
> appears to be the only place AbsoluteTime needs to be copied to a time_t
> variable. I can't find any other casts of AbsoluteTime to time_t,


> and
> with this patch applied all regression tests pass just fine (save for
> geometry of course with its standard off by one in nth decimal place
> difference).

Probably we should write that off as a platform issue and create an
Alpha-specific expected-output file for geometry.  See the documentation
about platform-specific files, and please send along a patch to add one.

> 	Additionally, I do not see how this patch could break other
> platforms. At worst, it is a minor slow down that might even be optimized
> out by some compiliers when they see that sizeof(AbsoluteTime) ==
> sizeof(time_t). I will defer to the core developers on how you want to
> apply this patch to the source tree (i.e. with #ifdef alpha && linux or as
> above).

No, we should just apply it as is, no #ifdef.  There are going to be
more and more platforms with 64-bit time_t.

			regards, tom lane

In response to


pgsql-ports by date

Next:From: Yutaka tanidaDate: 2000-06-26 11:33:11
Subject: Re: [HACKERS] .exe extension on Windows
Previous:From: Peter EisentrautDate: 2000-06-26 01:41:50
Subject: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-06-26 03:36:12
Subject: Re: [HACKERS] CLASSOID patch
Previous:From: Tom LaneDate: 2000-06-26 03:26:23
Subject: Re: Maximum len of data fit into the tuple

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group