Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> Certainly possible. At the moment the algorithm uses a binary search
> through a fixed size array of choices; reading from a table would
> require changes to a linked list or something else which is not quite as
Binary search doesn't depend on a fixed size table. How about:
1. At startup, read & parse TZ config file; build array and sort it.
2. During keyword lookup, first binary-search the array of fixed
keywords. If no match, binary-search the TZ array.
(This assumes that TZ names are not allowed to pre-empt other names,
such as month names. In some situations the parser might know that
a TZ name is expected, in which case it could go to the TZ array only,
thus allowing conflicting names to be resolved.)
> istm that a database table lookup is the way to internationalize and
> extend this area,
Um ... in the previous paragraph you were complaining about the
performance hit of doing a linear search. Which are you more concerned
about, speed or instant configurability?
This is by no means meant as an attack on the current implementation,
just a thought that we might be reaching its limits. If the Australians
want a configurable set of timezone names, why won't other areas?
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Thomas Lockhart||Date: 2002-02-26 03:53:53|
|Subject: Re: Timezone Inconsistancies|
|Previous:||From: Thomas Lockhart||Date: 2002-02-26 03:38:52|
|Subject: Re: More time zones|