BUG #5174: [minor] directories symlinked into base/ are not recursively removed

The following bug has been logged online:

Bug reference: 5174
Logged by: Richard Neill
Email address: rn214(at)cam(dot)ac(dot)uk
PostgreSQL version: 8.4.1
Operating system: Linux
Description: [minor] directories symlinked into base/ are not
recursively removed
Details:

This is rather a minor nit, but it might be a useful report. If not, sorry
for wasting your time.

Summary:
If subdirectories of base/ are actually symlinks, then postgresql deletes
just the symlink, not the directory.

To reproduce:

I had a system which was running out of disk space, and required a CLUSTER
to recover some. However, there wasn't actually enough space to run the
cluster operation. Therefore, I moved some of the larger subdirectories in
base/ to a different partition and symlinked them back.

For example:

service postgresql stop
cd /var/lib/postgresql/8.4/main/base/
mv 12345 /elsewhere
ln -s /elsewhere/12345 .
#repeat for a few directories.
service postgresql start

This allowed me to get the system running again, and to recover space on the
main partition.

On shutting down postgres again to clean up, I found that all the symlinks
were gone (good), but that the directories on the /elsewhere partition were
still all present, and full of (now-useless) data.

The (possible) bug:
I'd expect Postgresql to first follow the link, then recursively clean-out
the linked directory; then delete the link, leaving (at most) an empty
directory /elsewhere/12345

Actually, postgresql deleted the symlink, then left everything in /elsewhere
unchanged.

Comparison with rm:

mkdir a
touch a/b
ln -s a c
rm -rf c
#c is deleted; a and b remain untouched,

i.e. it does exactly the same thing that Postgresql did.

Conclusion:
I don't know if this is intentional; if not, then a minor RFE would be to
fix it.

Thanks for your help - Richard