Re: pgsql-server/ /configure /configure.in rc/incl ...
It doesn't even compile on my platform.
Then we have some work to do ... but that work won't get done
if the code is disabled by default.Or did we pick an upstream library so bad that it should be
*expected* to fail to compile everywhere? If that's true
then I can't trust it to work on Win32 either, and we should
be looking for another one.
[not sure if I can post to the -committers list, but since the therad is
there, giving it a try. Otherwise, the usual suspects will at least get
it in direct mail]
Certainly not, it compiles on a whole lot of platforms. I don't know if
does all the platforms postgres supports today, but it certainly does
most of them. It just requires a bunch of defines set in the Makefile.
This has to be done manually in the distribution. I'm sure this can
somehow be integrated with autoconf (some file mapping "our defines" to
"the librarys defines").
The defines are fairly well outlined in the makefile of the originaly
library (see link in readme file - I don't have it aroudn on this
machine, sorry), IIRC. Someone who knows more about exactly which of
these could/should be mapped how on the other platforms can probably say
something about how much work that integration would be.
I did the win32 part only, mainly because:
1) Win32 needed it badly. Since the current tz code was badly broken
there.
2) I'm not comfortable enough with hacking the autoconfified code myself
(yet), so I hoped someone else would do it. Bruce promised to pick up
the parts required to get it running on win32.
3) I was under the (apparantly incorrect?) impression that we wanted
this one up on win32 *now*, and then wanted to add it on other platforms
later.
//Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
3) I was under the (apparantly incorrect?) impression that we wanted
this one up on win32 *now*, and then wanted to add it on other platforms
later.
Well, that's an okay position if your time horizon is measured in days.
But I would like to see us using that code on all platforms before 7.5
feature freeze. It's silly to be carrying that code around and not
using it, when we have constant problems with the C-library-based time
zone code, plus big portability issues arising from inconsistency of
time zone names across platforms. For example, for the first time we'd
be able to actually document the set of time zone names accepted by
SET TIMEZONE, and *reliably* detect whether a provided name is really
legal.
Frankly I would never have accepted this patch if I thought it were
going to be a Windows-only hack; I would have held out for something a
lot smaller. In my mind the principal reason for having it is not Win32
at all, but solving the multi-platform problems we've always had with
time zone handling.
regards, tom lane
Tom Lane wrote:
"Magnus Hagander" <mha@sollentuna.net> writes:
3) I was under the (apparantly incorrect?) impression that we wanted
this one up on win32 *now*, and then wanted to add it on other platforms
later.Well, that's an okay position if your time horizon is measured in days.
But I would like to see us using that code on all platforms before 7.5
feature freeze. It's silly to be carrying that code around and not
using it, when we have constant problems with the C-library-based time
zone code, plus big portability issues arising from inconsistency of
time zone names across platforms. For example, for the first time we'd
be able to actually document the set of time zone names accepted by
SET TIMEZONE, and *reliably* detect whether a provided name is really
legal.Frankly I would never have accepted this patch if I thought it were
going to be a Windows-only hack; I would have held out for something a
lot smaller. In my mind the principal reason for having it is not Win32
at all, but solving the multi-platform problems we've always had with
time zone handling.
It goes with the Win32 approach of doing as little as possible to the
Unix port. If the Unix folks want it, we can enable it, but the Win32
folks aren't going to force it on Unix until Unix wants it and has
tested it.
I am not going to give Win32 a bad name by breaking the CVS build for
everyone. You guys are very sensitive to Win32 mucking up the Unix
port, so this is what you get --- a Win32 port that makes the minimal
disruption to Unix.
--
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, Pennsylvania 19073
On Fri, 30 Apr 2004, Bruce Momjian wrote:
Tom Lane wrote:
"Magnus Hagander" <mha@sollentuna.net> writes:
3) I was under the (apparantly incorrect?) impression that we wanted
this one up on win32 *now*, and then wanted to add it on other platforms
later.Well, that's an okay position if your time horizon is measured in days.
But I would like to see us using that code on all platforms before 7.5
feature freeze. It's silly to be carrying that code around and not
using it, when we have constant problems with the C-library-based time
zone code, plus big portability issues arising from inconsistency of
time zone names across platforms. For example, for the first time we'd
be able to actually document the set of time zone names accepted by
SET TIMEZONE, and *reliably* detect whether a provided name is really
legal.Frankly I would never have accepted this patch if I thought it were
going to be a Windows-only hack; I would have held out for something a
lot smaller. In my mind the principal reason for having it is not Win32
at all, but solving the multi-platform problems we've always had with
time zone handling.It goes with the Win32 approach of doing as little as possible to the
Unix port. If the Unix folks want it, we can enable it, but the Win32
folks aren't going to force it on Unix until Unix wants it and has
tested it.
Unix wants it and is willing to spend the next month testing it to make
sure its good :)
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
Well, that's an okay position if your time horizon is measured in days.
But I would like to see us using that code on all platforms before 7.5
feature freeze. It's silly to be carrying that code around and not
using it, when we have constant problems with the C-library-based time
zone code, plus big portability issues arising from inconsistency of
time zone names across platforms. For example, for the first time we'd
be able to actually document the set of time zone names accepted by
SET TIMEZONE, and *reliably* detect whether a provided name is really
legal.Frankly I would never have accepted this patch if I thought it were
going to be a Windows-only hack; I would have held out for something a
lot smaller. In my mind the principal reason for having it is not Win32
at all, but solving the multi-platform problems we've always had with
time zone handling.It goes with the Win32 approach of doing as little as possible to the
Unix port. If the Unix folks want it, we can enable it, but the Win32
folks aren't going to force it on Unix until Unix wants it and has
tested it.Unix wants it and is willing to spend the next month testing it to make
sure its good :)
OK, let me get it working on my Unix first and then I will give
instructions for others on how to test it. Once a few have tested that
it works, we can enable it for all ports and rip out the PGTZ tests.
--
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, Pennsylvania 19073
On 30-Apr-04, at 12:14 PM, Bruce Momjian wrote:
It goes with the Win32 approach of doing as little as possible to the
Unix port. If the Unix folks want it, we can enable it, but the Win32
folks aren't going to force it on Unix until Unix wants it and has
tested it.
I completely agree with Tom and Marc -- if we're going to do this at
all, we should use the timezone library for all platforms. Since that
is the only plausible way we could release 7.5 in my view, the sooner
we get testing of the code on all platforms, the better.
I have no problem if you would like to delay doing this for a matter of
days or hours so that you've got it working on one platform before
enabling it for others, but I would like to see it enabled for all
platforms soon.
-Neil
Bruce Momjian <pgman@candle.pha.pa.us> writes:
It goes with the Win32 approach of doing as little as possible to the
Unix port.
That's *not* the approach I want to take. What I want is a Windows port
that adds as little #ifdef cruft to the system as possible --- that is,
no duplicate code paths that are used for only some platforms. A port
that uses an entire timezone library that's not used elsewhere doesn't
fit that criterion.
Besides which, as I tried to explain already, a large part of the reason
for wanting to solve the Windows datetime problem in this particular way
was the knowledge that we could solve a lot of existing problems on
various Unixen by adopting the same code cross-platform.
What you're wanting to do seems a lot like what would happen if I were
to write the fsync/sync-in-bgwriter code that I plan to do next week,
and then commit it all as #ifdef WIN32 in parallel with the existing way
of doing things. It would be an ugly mess, and you'd quite rightly tell
me off for it ...
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
It goes with the Win32 approach of doing as little as possible to the
Unix port.That's *not* the approach I want to take. What I want is a Windows port
that adds as little #ifdef cruft to the system as possible --- that is,
no duplicate code paths that are used for only some platforms. A port
that uses an entire timezone library that's not used elsewhere doesn't
fit that criterion.Besides which, as I tried to explain already, a large part of the reason
for wanting to solve the Windows datetime problem in this particular way
was the knowledge that we could solve a lot of existing problems on
various Unixen by adopting the same code cross-platform.What you're wanting to do seems a lot like what would happen if I were
to write the fsync/sync-in-bgwriter code that I plan to do next week,
and then commit it all as #ifdef WIN32 in parallel with the existing way
of doing things. It would be an ugly mess, and you'd quite rightly tell
me off for it ...
The timezone library is going to break the Unix build.
The group is very quick to gruble when the Win32 does something that
makes the Unix code less pleasant. Are you telling me folks would be
complaining if I committed the timezone code and broke all the builds,
not just the Win32 one? You sure would.
I never said I wasn't going to enable it for Win32, but I am only going
to do it when the unix build is better tested, and right now it doesn't
even work on my unix machine.
--
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, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
I never said I wasn't going to enable it for Win32, but I am only going
to do it when the unix build is better tested, and right now it doesn't
even work on my unix machine.
Well, if you'd said "I'm holding off enabling it globally just until
I can figure out why it doesn't work for me", no one would have
complained. That wasn't my reading of what you said though...
I'll give you a hint what to try: convert all those K&R function headers
to ANSI C style. They are portability failures waiting to happen, so
maybe they're already happening to you.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I never said I wasn't going to enable it for Win32, but I am only going
to do it when the unix build is better tested, and right now it doesn't
even work on my unix machine.Well, if you'd said "I'm holding off enabling it globally just until
I can figure out why it doesn't work for me", no one would have
complained. That wasn't my reading of what you said though...I'll give you a hint what to try: convert all those K&R function headers
to ANSI C style. They are portability failures waiting to happen, so
maybe they're already happening to you.
How do I do that?
It is behaving like it doesn't see the timezone database at all.
--
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, Pennsylvania 19073Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
I never said I wasn't going to enable it for Win32, but I am only going
to do it when the unix build is better tested, and right now it doesn't
even work on my unix machine.Well, if you'd said "I'm holding off enabling it globally just until
I can figure out why it doesn't work for me", no one would have
complained. That wasn't my reading of what you said though...
Even if it worked for me, I wouldn't have enabled it by default for
Unix. I would have waited for others to test it and say they liked it.
People are so quick to complain, I do the minimal I have to to get Win32
working with minimal disruption to Unix.
--
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, Pennsylvania 19073