[no subject]

>XML files are relatively easy to parse, but they certainly aren't as
>easy as simply letting PostgreSQL follow a symlink.  Why reinvent the
>wheel with what would essentially be PostgreSQL's own implementation
>of a symlink?
>  
>

Is opening a file recreating a symlink?  If you are opening file
descriptors why rely on symlinks.  If you know the location either from
the system catalog, a or configuration file, is it any terribly more
complicated?   Basically, if a tablespace needed to be renamed, or
moved, or changed, your going to have to do file management anyway.  
The symlink saves you just a lookup as to what files go where?  If you
kept this small hash in memory, it's not a continuous lookup because you
have the redirection internally.  And, it's more portable.

>To go back to your *tar* example, are we going to rewrite tar so that
>it reads PostgreSQL's XML file and *does the right thing*?
>  
>

I'm not talking about integrating tar with PostgreSQL or uniting the
universal string theory with how to cook apple pie.  Why would think we
would have to rewrite tar?

>  
>
>>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.
>>    
>>
>
>Yes, and someone can whip out vi and edit a file or fire up psql and
>change the system catalog.  Heck, someone could issue a 'mv' or 'rm'
>command on the actual files, for that matter.  PostgreSQL can't
>protect itself from careless sysadmins, and symlinks are no more
>inherently dangerous than normal files.  They don't just *disappear*.
>
>  
>
>>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.
>>    
>>
>
>The fact of the matter is that PostgreSQL runs better on some
>platforms than others, and it probably always will.  Heck, as of
>today, PostgreSQL is officially supported on the Gamecube.  Does that
>mean that the PostgreSQL developers should limit themselves to the
>features offered by the Gamecube?  What, precisely, is the point of
>developing for the lowest common denominator?
>  
>

The other option proposed was to give win32 a subset of features that
would be available to other platforms.  In this case, that would be that
the win32 port could support tablespaces.  This is strikingly different
than a performance issue.   It would be one thing for tablespaces to
perform poorly, it's another for them to fail or not exist altogether.

>Perhaps if you could give us an example of an actual case where some
>actual PostgreSQL users (or potential users) might be affected?
>  
>

See the comment from Tom Lane on limiting features.  Look at the
potential Win32 market which outnumbers the unix market in number of
computers and developers by a large margin.