Sorry to reply, but there should also be a field in the system view
"is_alias" so that devs are able to tell which zone names are in the
zone.tab file and which are not. That way a perfect 1:1 mapping between
zone.tab and app can be made. If this were done then it'd make things
like using CLDR data and other standardized data sources easier, as you
could be confident that all timezone names matched the data in the CLDR.
I think what I'm trying to say is that using and applying standards is a
good thing.
- Naz.
Naz Gassiep wrote:
Is there any reason that the zone.tab information is not included in
the pg_timezone_names system view? ISTM that there is really no reason
not to, as that view is really populated using that file anyway. There
is a 1:1 mapping (assuming the aliases are mapped to the zone.tab
entries they are aliases of) of entries in that view with enties in
zone.tab.
Reading an earlier thread on this matter, I think Magnus is behind the
code that generates the view. What are the chances of getting at least
the country code included in the pg_timezone_names system view? It'd
really help out with i18n / L10n work, and given that PG already ships
with that data present, it seems silly to not take advantage of it
given how easy it would be to do so.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
