mirror of
https://github.com/postgres/postgres.git
synced 2026-02-16 17:19:08 -05:00
54d60bbd07
settings: avoid calling superuser() in contexts where it's not defined, don't leak the transient copies of GetConfigOption output, and avoid the whole exercise in postmaster child processes. I found that actually no current caller of GetConfigOption has any use for its internal check of GUC_SUPERUSER_ONLY. But rather than just remove that entirely, it seemed better to add a parameter indicating whether to enforce the check. Per report from Simon and subsequent testing. |
||
|---|---|---|
| .. | ||
| data | ||
| tznames | ||
| ialloc.c | ||
| localtime.c | ||
| Makefile | ||
| pgtz.c | ||
| pgtz.h | ||
| private.h | ||
| README | ||
| scheck.c | ||
| strftime.c | ||
| tzfile.h | ||
| zic.c | ||
$PostgreSQL: pgsql/src/timezone/README,v 1.7 2008/03/21 13:23:29 momjian Exp $ Timezone ======== This is a PostgreSQL adapted version of the timezone library from: ftp://elsie.nci.nih.gov/pub/tzcode*.tar.gz The code is currently synced with release 2007k. There are many cosmetic (and not so cosmetic) differences from the original tzcode library, but diffs in the upstream version should usually be propagated to our version. The data files under data/ are an exact copy of the latest data set from: ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz Since time zone rules change frequently in some parts of the world, we should endeavor to update the data files before each PostgreSQL release. At each update, we should check if time zone offsets have changed. Just search for the current or previous year and see what has changed. Sometimes a country changes its time zone offsets, for example Georgia in 2004. Just grepping in the zic database files for 2004 is enough to spot such a change. Then the files under tznames/ should be updated.