Peter Eisentraut <[EMAIL PROTECTED]> 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-wi
Okay, so we'll do the symlinks.
CREATE DATABASE xxx WITH LOCATION='/else/where';
will clone ('cp -r') template1 in /else/where/base/ and create a
symlink to there from $PGDATA/base/. The '/else/where' location will
be stored in pg_database.datpath.
How do we control the allowed paths? Should
On Mon, Nov 06, 2000 at 12:13:31PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > Hmm, I know NT's not really a target, supported OS, but enshrining
> > symlinks in a the design of a backend feature makes it really difficult
> > to keep even the semblance of support.
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> Hmm, I know NT's not really a target, supported OS, but enshrining
> symlinks in a the design of a backend feature makes it really difficult
> to keep even the semblance of support.
As long as we don't require symlinks to exist for standard setups
On Sat, Nov 04, 2000 at 10:09:16PM -0800, Vadim Mikheev wrote:
> > >> I think that to handle locations we could symlink catalogs - ln -s
> > >> path_to_database_in_some_location .../base/DatabaseOid
> >
> > > But that's a kludge. We ought to discourage people from messing with the
> > > storage
> >> I think that to handle locations we could symlink catalogs - ln -s
> >> path_to_database_in_some_location .../base/DatabaseOid
>
> > But that's a kludge. We ought to discourage people from messing with the
> > storage internals.
>
> It's not a kluge, it's a perfectly fine implementation.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But RelFileNode already claims to store the identity of the table space,
> being the database oid. This doesn't work because a location can contain
> more than one database. So effectively we'd need to redefine RelFileNode
> something like 'struct {
> With the new oid file naming, the alternative database
> location feature has disappeared. Not good.
>
> Also, is there any merit in keeping the #ifdef
> OLD_FILE_NAMING code path?
No one. I've removed some of old code but not all, sorry.
> I could probably go through and fix this, but I'm
