
> The current discussion of symlinks is focusing on using directory
> symlinks, not file symlinks, to represent/implement tablespace layout.

If that is the only issue for the symlinks, I think it would be sufficient
to 
put the files in the correct subdirectories. The dba can then decide
whether he wants to mount filsystems directly to the disired location, 
or create a symlink. I do not see an advantage in creating a symlink
in the backend, since the dba has to create the filesystems anyway.

fs: data
fs: data/base/...../extent1
link: data/base/...../extent2 -> /data/extent2
...

Andreas

Wed, 21 Jun 2000 11:49:26 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Big 7.1 open items 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
>> The current discussion of symlinks is focusing on using directory
>> symlinks, not file symlinks, to represent/implement tablespace layout.

> If that is the only issue for the symlinks, I think it would be sufficient
> to 
> put the files in the correct subdirectories. The dba can then decide
> whether he wants to mount filsystems directly to the disired location, 
> or create a symlink. I do not see an advantage in creating a symlink
> in the backend, since the dba has to create the filesystems anyway.

> fs: data
> fs: data/base/...../extent1
> link: data/base/...../extent2 -> /data/extent2

That (mounting a filesystem directly where the symlink would otherwise
be) would be OK if you were making a new filesystem that you intended to
use *only* as database storage, and *only* for one database ... maybe
even just one extent subdir of one database.  I'd accept it as being an
OK answer for anyone unfortunate enough not to have symlinks, but for
most people symlinks would be more flexible.

			regards, tom lane

Wed, 21 Jun 2000 11:58:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: Big 7.1 open items 