[HACKERS] BLOBs and a virtual file system
Lately I've been planning work on a patch to postgres and linux on my system to allow access to BLOBs as a virtual filesystem, so I can see any file I put in there even through network shares while avoiding duplication / broken link issues. Does this sound like something worth doing / is there a better way to safely reference files from both inside and outside postgres? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] BLOBs and a virtual file system
Peter Martini [EMAIL PROTECTED] writes: Lately I've been planning work on a patch to postgres and linux on my system to allow access to BLOBs as a virtual filesystem, so I can see any file I put in there even through network shares while avoiding duplication / broken link issues. Does this sound like something worth doing / is there a better way to safely reference files from both inside and outside postgres? How would you do that without breaking transactional integrity for blobs? There'd be no way to deal with multiple row versions in such a representation. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] BLOBs and a virtual file system
Peter Martini writes: Lately I've been planning work on a patch to postgres and linux on my system to allow access to BLOBs as a virtual filesystem, so I can see any file I put in there even through network shares while avoiding duplication / broken link issues. Does this sound like something worth doing / is there a better way to safely reference files from both inside and outside postgres? I have been looking into using the Tcl VFS features for this kind of thing. I work with AOLserver and PostgreSQL so I have Tcl and PostgreSQL available to me. http://nnsa.dl.ac.uk/MIDAS/manual/ActiveTcl8.4.4.0-html/tclvfs/doc/vfs.html I haven't thought about accessing the VFS from inside PostgreSQL though. Dave Bauer [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] BLOBs and a virtual file system
I'm not sure what you mean by breaking blobs transactional integrity. Do you mean by allowing filesystem type access, the blobs won't be properly locked and updated during a transaction? If so, that's exactly what I'm trying to achieve - a compromise between forcing the files to be stored solely in the database (maintaining integrity but sacrificing functionality) or referencing their names to gain functionality, but at a greater cost. More to the point, wouldn't file locking mechanisms, and the possibility of limiting file visibility through the virtual filesystem, allow transactional integrity to be maintained? If not, could you explain where the problem is so I can look further into it? Thanks, Peter On Wed, 2004-06-23 at 11:48, Tom Lane wrote: Peter Martini [EMAIL PROTECTED] writes: Lately I've been planning work on a patch to postgres and linux on my system to allow access to BLOBs as a virtual filesystem, so I can see any file I put in there even through network shares while avoiding duplication / broken link issues. Does this sound like something worth doing / is there a better way to safely reference files from both inside and outside postgres? How would you do that without breaking transactional integrity for blobs? There'd be no way to deal with multiple row versions in such a representation. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] BLOBs and a virtual file system
On Wed, 23 Jun 2004 15:07:42 -0400 Peter Martini [EMAIL PROTECTED] wrote: I'm not sure what you mean by breaking blobs transactional integrity. Do you mean by allowing filesystem type access, the blobs won't be properly locked and updated during a transaction? If so, that's exactly what I'm trying to achieve - a compromise between forcing the files to be stored solely in the database (maintaining integrity but sacrificing functionality) or referencing their names to gain functionality, but at a greater cost. More to the point, wouldn't file locking mechanisms, and the possibility of limiting file visibility through the virtual filesystem, allow transactional integrity to be maintained? If not, could you explain where the problem is so I can look further into it? I believe the problem is that the blob could be in several different states inside of several different transactions. How do you determine which you show in the filesystem? Even if the file system is read only you still have this problem of which of the many possible BLOBs to reveal. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
