Обсуждение: pgsql-server/ /configure /configure.in rc/incl ...
pgsql-server/ /configure /configure.in rc/incl ...
От
momjian@svr1.postgresql.org (Bruce Momjian)
Дата:
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: momjian@svr1.postgresql.org 04/04/30 01:18:28
Modified files:
. : configure configure.in
src/include : pg_config.h.in
Log message:
Enable use of our own timezone library for Win32.
momjian@svr1.postgresql.org (Bruce Momjian) writes:
> Enable use of our own timezone library for Win32.
If we're going to accept having our own timezone library, it should be
used on all platforms. We have *more* than enough reasons to want to
do this, we just had not swallowed hard enough to plop such a library
into the distro. Now that it's there, using it on only one platform is
the worst of all possible worlds.
regards, tom lane
Tom Lane wrote: > momjian@svr1.postgresql.org (Bruce Momjian) writes: > > Enable use of our own timezone library for Win32. > > If we're going to accept having our own timezone library, it should be > used on all platforms. We have *more* than enough reasons to want to > do this, we just had not swallowed hard enough to plop such a library > into the distro. Now that it's there, using it on only one platform is > the worst of all possible worlds. Not to me. We will enable on Unix when we it is tested and we are happy with it. -- 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: > > momjian@svr1.postgresql.org (Bruce Momjian) writes: > > > Enable use of our own timezone library for Win32. > > > > If we're going to accept having our own timezone library, it should be > > used on all platforms. We have *more* than enough reasons to want to > > do this, we just had not swallowed hard enough to plop such a library > > into the distro. Now that it's there, using it on only one platform is > > the worst of all possible worlds. > > Not to me. We will enable on Unix when we it is tested and we are happy > with it. and, of course, it will be tested sometime after it is enabled ... we are in a dev cycle still, enable it and see what bugs are reported ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Fri, 30 Apr 2004, Bruce Momjian wrote: > > > Tom Lane wrote: > > > momjian@svr1.postgresql.org (Bruce Momjian) writes: > > > > Enable use of our own timezone library for Win32. > > > > > > If we're going to accept having our own timezone library, it should be > > > used on all platforms. We have *more* than enough reasons to want to > > > do this, we just had not swallowed hard enough to plop such a library > > > into the distro. Now that it's there, using it on only one platform is > > > the worst of all possible worlds. > > > > Not to me. We will enable on Unix when we it is tested and we are happy > > with it. > > and, of course, it will be tested sometime after it is enabled ... we are > in a dev cycle still, enable it and see what bugs are reported ... It doesn't even compile on my platform. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Now that it's there, using it on only one platform is
>> the worst of all possible worlds.
> Not to me. We will enable on Unix when we it is tested and we are happy
> with it.
And if it's not enabled, how will it get tested? Your logic is circular.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.
regards, tom lane
> > 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
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 19073
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.
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 19073
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... 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