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])
