| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Vadim Mikheev <vmikheev(at)sectorbase(dot)com> |
| Subject: | Re: Alternative database locations are broken |
| Date: | 2000-11-06 20:08:13 |
| Message-ID: | 16178.973541293@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> How do we control the allowed paths? Should we continue with the
> environment variables? Perhaps a config option listing the allowed
> directories? A system catalog?
The environment variables are a pretty sucky mechanism, IMHO;
an installation-wide catalog would be nicer. HOWEVER: I do not
think it's reasonable to try to make that happen for 7.1, considering
how close we are to beta. So I recommend that we continue to base
allowed paths on environment variables for this release.
> Somehow I also get the feeling that pg_dumpall should be saving these
> paths...
Yup, probably so. If you stick the LOCATION string into
pg_database.datpath (which no longer has any other use)
then it'd be easy to make pg_dumpall do so.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mikheev, Vadim | 2000-11-06 20:56:10 | RE: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.c) |
| Previous Message | Peter Eisentraut | 2000-11-06 19:33:55 | Re: Alternative database locations are broken |