Re: Alternative database locations are broken

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 internals.
> > 
> > It's not a kluge, it's a perfectly fine implementation.  The only kluge
> > here is if people have to reach in and establish such symlinks by hand.
> > We want to set up a user interface that hides the implementation.
> 
> Agreed. And I don't see problems with handling this at CREATE DATABASE
> time. Create database dir in specified location, create symlink from
> base dir and remember location name in pg_database.datpath.
> 

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. Vadim's work _finally_ stomped
the mixed case tablename bug ("Test" and "test" would collide because of
NTFSi being case insensitive).  Symlinks are, I think, only supported via
a Cygwin kludge. 

'Course, one could argue that running pgsql via Cygwin is all a big
kludge. I'm not even sure why I keep coming to the defense of the NT
port: I'm not using it myself. I keep getting the feeling that there's a
real opportunity there: get pgsql onto developer's NT boxes, when their
projects need a real database, rather than springing for an MS-SQL or
Oracle license.  Makes moving over to a _real_ operating system (when
they start to notice those stability problems) that much easier.

But seriously, there was a long thread concerning the appropriateness
of using symlinks to manage storage, which I don't recall as coming
to a conclusion. Admittedly, the opinion of those who take the bull by
the horns and actually write the code matters more (rough concensus and
working code, as they say).

Ross
-- 
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers 
and users independent of economic motivations.  Jim Flynn, Sunnyvale, Calif.