From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | BRUSSER Michael <Michael(dot)BRUSSER(at)3ds(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: initdb failure with Postgres 8.4.4 |
Date: | 2010-12-13 18:02:29 |
Message-ID: | 24189.1292263349@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 12/13/2010 12:16 PM, BRUSSER Michael wrote:
>> Would it be a completely crazy idea if I try to modify Postgres to look at some env. var
>> (similar to PGDATA) and if exists and path is valid look there for the timezone files?
> Yes, that's only the first problem you have encountered. I predict there
> will be others if you go down this path.
As far as the timezone data files go, you might have use for the
--with-system-tzdata configure option. Note that that is not an
"environment variable"; it requires a hard coded path to the system
copy of the Olsen timezone database. The expectation is that any
system-maintained copy will have a very well-defined location for
those files on any given platform, so there is no need for runtime
tweaking. You would use this only on platforms where you expect
that normal system maintenance procedures will keep the TZ files more
up-to-date than the ones included with Postgres.
I agree with Andrew's point in general. Trying to customize the
relative layout of the various Postgres-installed files is an
exercise in pointless pain.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-12-13 18:05:37 | Re: hstores in pl/python |
Previous Message | Joshua Tolley | 2010-12-13 17:59:01 | Re: proposal : cross-column stats |