...
> Well, this does sound a bit more involved than I was envisioning. There
> are a few items wrt SRFs that I should finish first, but I'll come back
> to this afterward if no one else does first.
The first cut might be to reproduce the functionality we already have.
That would allow us to (optionally) use this internal code *or* the
system-provided code with a configure-time switch. We could then strip
out two of the three time zone interface styles we support. And we could
(possibly) allow folks to use their built-in time zone databases if they
want, to minimize inconsistancies between PostgreSQL and other programs
on the system. We might need to modify function and variable signatures
to avoid conflicts with system-supplied libraries.
The next step would be to see how to generalize this past Y2038 (as
mentioned previously, time zone info for pre-1900 is not likely to be
interesting). If it involves mass substitution of time_t for, say,
pg_time_t, then that might be all we need for the second phase, at which
time we've broken the y2038 limit by moving to 64-bit integer time.
The last phase could be extending the API to allow multiple simultaneous
time zones, detection of bad time zones, etc etc. This would involve API
changes or extensions, and breaks compatibility with system-supplied
infrastructure.
- Thomas
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
