"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> I'm not wedded to "forks", that's just the name that was used in the
> only previous example I've seen. Classic Mac had a "resource fork"
> and a "data fork" within each file.
fwiw forks are not unique to MacOS, c.f.:
http://en.wikipedia.org/wiki/Fork_%28filesystem%29
However I'm not sure reusing any of these terms is such a hot idea. All it's
going to do is confuse someone into thinking we're actually talking about HFS
forks or NTFS data streams or whatever. Better to pick a term that isn't
already being used for such things so people don't get misled.
> BTW, thinking about the Mac precedent a little more, I believe
> the way they grafted that Classic concept onto BSD was that
> applications (which the user thinks of as single objects) are
> now directories with multiple files inside them. Probably it'd be
> overkill to think of turning each relation into a subdirectory, but
> then again maybe not?
Well there are upsides and downsides. Many OSes have difficulties when you
have many files in a single directory. This would tend to reduce that. On the
other hand it would drastically increase the number of directory files the OS
has to keep track of and the total number of inodes being referenced.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!