tablespaces and non-empty directories

I assume CREATE TABLESPACE refuses to use a non-empty directory because of the 
risk of trashing existing files. Makes sense, but consider the following:

# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
# chown postgres /mnt/pg_tables
# su -c psql pyarra
pyarra=# CREATE TABLESPACE spc_tables LOCATION '/mnt/pg_tables/';
ERROR:  directory "/mnt/pg_tables" is not empty

This is because lost+found exists. Since lost+found would be a reasonably 
common directory to find at a mount-point on Unix-like OSs*, would it make 
sense for CREATE TABLESPACE to ignore it if present?

Of course this isn't hard to get around:
# mkdir /mnt/pg_tables/data
# chown postgres /mnt/pg_tables/data
CREATE TABLESPACE spc_tables LOCATION '/mnt/pg_tables/data/';

If consensus is that it is a bad idea to treat lost+found as a special case, 
would it be worth putting an explicit mention in the doco about the preferred 
way to set up a database with multiple disks?

Related question: are there plans afoot to allow specifying an alternate 
location for pg_xlog (or pg_delete-me-not) to save doing the shutdown-DB, mv 
directory to other disk, symlink, start-DB dance?

Regards, Philip.

* Solaris 9 and Linux both use lost+found, Tru64 v4.0f does not seem to (and 
has extra guff for quota management too). I doubt we could cater to every 
possible Unix OS and the administrative files it creates at mount points, 
however since lost+found is so common, if it's there, we could ignore it.

-- 

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd 
This message has been scanned for viruses and
dangerous content by Utiba mail server and is 
believed to be clean.