Thread: pgsql-server/src/timezone pgtz.h

CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    momjian@svr1.postgresql.org    04/04/30 13:58:48

Modified files:
    src/timezone   : pgtz.h

Log message:
    Timezone code checks for HAVE_SYMLINK of zero, so use in pgtz.h:

    #ifndef HAVE_SYMLINK
    #define HAVE_SYMLINK 0
    #endif

momjian@svr1.postgresql.org (Bruce Momjian) writes:
>     Timezone code checks for HAVE_SYMLINK of zero, so use in pgtz.h:

>     #ifndef HAVE_SYMLINK
>     #define HAVE_SYMLINK 0
>     #endif

Surely this is exactly the wrong thing to do.  It will break code that
tests for #ifdef HAVE_SYMLINK.  Shouldn't you instead fix the timezone
library to make its tests in a more standard way?

            regards, tom lane

Tom Lane wrote:
> momjian@svr1.postgresql.org (Bruce Momjian) writes:
> >     Timezone code checks for HAVE_SYMLINK of zero, so use in pgtz.h:
>
> >     #ifndef HAVE_SYMLINK
> >     #define HAVE_SYMLINK 0
> >     #endif
>
> Surely this is exactly the wrong thing to do.  It will break code that
> tests for #ifdef HAVE_SYMLINK.  Shouldn't you instead fix the timezone
> library to make its tests in a more standard way?

I thought about that but I figured the less we change the tz library,
the easier it will be to replace later.  The code uses a zero test
rather than an undef test, and that seemed OK to me assuming we will not
be mucking with this code 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

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I thought about that but I figured the less we change the tz library,
> the easier it will be to replace later.

I have come to the conclusion that trying to minimize changes to the tz
library is a bad tradeoff.  It's not going to be a minimally sized diff
for long.  For instance, do you propose to exclude the tz code from all
future pgindent runs?  If you look at the changes we made in the regex
library to make it minimally compliant with our own coding standards,
they were pretty extensive.  The same is probably going to happen to the
tz code.  For one thing, it is definitely not going to have K&R-style
function declarations for long --- those are trouble waiting to happen.

For another thing, it's not going to try to emulate the C library's API
for long, because getting out from under that brain-dead API is exactly
the reason for wanting to have our own timezone code.  (I suspect the
only part of this code we really want in the long run is zic.c.)

In any case we should certainly not fix portability failures in the tz
code by breaking our other code, or even just risking breaking it.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I thought about that but I figured the less we change the tz library,
> > the easier it will be to replace later.
>
> I have come to the conclusion that trying to minimize changes to the tz
> library is a bad tradeoff.  It's not going to be a minimally sized diff
> for long.  For instance, do you propose to exclude the tz code from all
> future pgindent runs?  If you look at the changes we made in the regex
> library to make it minimally compliant with our own coding standards,
> they were pretty extensive.  The same is probably going to happen to the
> tz code.  For one thing, it is definitely not going to have K&R-style
> function declarations for long --- those are trouble waiting to happen.
>
> For another thing, it's not going to try to emulate the C library's API
> for long, because getting out from under that brain-dead API is exactly
> the reason for wanting to have our own timezone code.  (I suspect the
> only part of this code we really want in the long run is zic.c.)
>
> In any case we should certainly not fix portability failures in the tz
> code by breaking our other code, or even just risking breaking it.

I wasn't aware we were going to be gutting it.  I am still trying to
just get it to work on 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