Re: [HACKERS] Tablespaces

> tswan(at)idigx(dot)com wrote:
>> > "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> >>>> My feeling is that we need not support tablespaces on OS's without
>> >>>> symlinks.
>> >
>> >> To create symlinked directories on Win2k NTFS see:
>> >> http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
>> >> I think Win2000 or XP would be a reasonable restriction for Win32 PG
>> >> installations that want tablespaces.
>> >
>> > Oh, good --- symlinks for directories are all that we need for this
>> > design. I think that settles it then.
>> >
>>
>> What archival tools are there that would restore this to this back to
>> the
>> filesystem: tar? zip? What would happen if a symlink were removed or
>> pointed to an invalid location while the postmaste was running?
>
> Well, for backup, just run tar or find on /data with a flag to follow
> symlinks, and you are done. Can't get much easier than that.

I'm ruferring to NTFS and the win32 platforms. How does tar handle these
symlinks on the NTFS filesystem? What about if someone finds that FAT32
is significantly better for the database?

It seems a little insane to introduce an OS/filesystem dependency at the
onset of a porting effort especially if you hope to be OS agnostic for
feature sets. I think someone would be crying foul if a new feature only
worked on Linux and not on FreeBSD.

Additionally, another developer noted the advantage of a text file is that
it would be easy for someone to develop tools to help if it became
difficult to edit or parse. Additionally, there could be a change away
from a flat file format to an XML format to configure the tablespace area.

Another argument against the symlink approach is how they may change in
the future. A file location is universal, symlink behavoir may not be.
The symlink behavior on different ports may change. To rely on symlinks
introduces an unnecessary OS dependency. All that is needed is the file
location. This can be derived from a flat file, an XML file, a sysetm
catalog.

Also, to support some features on some platforms is a real poor prospect.
( This application requires the Linux port of PostgreSQL 7.5.1 ) seems
like a poor choice for advocating PostgreSQL. The extra effort insures
that all ports, current and future, can get the same set of features and
nhancements. I like Unix and Linux as much as the next guy, but I have
to be real and make the presumption that there are and will be other
operating systems and it would be wise to plan a little for that.