Re: Proposal: More portable way to support 64bit platforms - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Proposal: More portable way to support 64bit platforms
Date
Msg-id 200908041710.05500.peter_e@gmx.net
Whole thread Raw
In response to Re: Proposal: More portable way to support 64bit platforms  (Tsutomu Yamada <tsutomu@sraoss.co.jp>)
Responses Re: Proposal: More portable way to support 64bit platforms
List pgsql-hackers
On Tuesday 04 August 2009 14:03:34 Tsutomu Yamada wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>  > On Fri, Jul 24, 2009 at 4:24 PM, Peter Eisentraut<peter_e@gmx.net> wrote:
>  > > On Friday 26 June 2009 12:07:24 Tsutomu Yamada wrote:
>  > >> Included is a conceptual patch to use intptr_t. Comments are welcome.
>  > >
>  > > After closer inspection, not having a win64 box available, I have my
>  > > doubts whether this patch actually does anything. Foremost, it doesn't
>  > > touch the definition of the Datum type, which ought to be at the core
>  > > of a change like this.
>  > >
>  > > Now I see that you call this a "conceptual patch". Perhaps we should
>  > > wait until you have developed it into a complete patch?
>  >
>  > Is there any reason to consider this patch any further during this
>  > CommitFest?  It seems that this is a long way from being ready to go.
>
> I'm sorry for delaying response.
>
> This patch is needed as a base of the fix for Windows x64 in the future.
>
> There are still a lot of corrections necessary for Win x64.
> (typedef Datum, shared buffer, "%lu" messages, headers, build scripts, ...)
> We are trying these now, and want to offer the result to the next Commit
> Fest.
>
> Because we are glad if this pointer patch is confirmed at the early stage,
> we submitted patch to this Commit Fest.

Well, there is nothing outright wrong with this patch, but without any 
measurable effect, it is too early to commit it.  At least I would like to see 
the Datum typedef to be changed to use intptr_t and the fallout from that 
cleaned up.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_proc.probin should become text?
Next
From: Peter Eisentraut
Date:
Subject: Re: bytea vs. pg_dump