Обсуждение: Supporting SQL/MED DATALINK
Hello,
Do you plan on supporting SQL/MED features concerning DATALINKs?
I've seen DATALINK mentionned on the Wiki [1] but I couldn't find it on the TODO list [2].
By the way, do you know any vendor that provides support for DATALINK?
Except DB2, there seems to be very little "visibility" of this 2003 feature in the whole SQL world !
Regards,
Damiano ALBANI
On fre, 2012-01-06 at 15:53 +0100, Damiano ALBANI wrote: > Do you plan on supporting SQL/MED features concerning DATALINKs? > I've seen DATALINK mentionned on the Wiki [1] but I couldn't find it on the > TODO list [2]. I'm not aware of any plans. What would be your use case? > By the way, do you know any vendor that provides support for DATALINK? > Except DB2, there seems to be very little "visibility" of this 2003 feature > in the whole SQL world ! I believe DB2 is pretty much it in this area.
On Sun, Jan 8, 2012 at 21:13, Peter Eisentraut <peter_e@gmx.net> wrote:
What I'm most interested in are the "transaction" and "auto deletion of unused file" features of DATALINK.I'm not aware of any plans. What would be your use case?
Well, basically what DATALINK is made for: storing files in the filesystem and only keeping the reference in the database.
At the moment, this is handled by some code in my application (although not perfectly, e.g. regarding transactions), so I can live with that :-)
I believe DB2 is pretty much it in this area.
For the record, it looks like MS SQL Server has some equivalent feature : FILESTREAM.
Damiano ALBANI
On 9 January 2012 09:56, Damiano ALBANI >> I believe DB2 is pretty much it in this area. > > For the record, it looks like MS SQL Server has some equivalent feature : > FILESTREAM. And Oracle has BFILE. I've actually been thinking about how to implement something like this for Postgres, but the interaction with the file-system makes it a little more difficult to implement. Someone shouldn't be able to delete a file from the file-system that's still referenced from the database. Perhaps a file-system layer with FusionFS would be a suitable solution for something like this, but I couldn't convince myself that it is. In the end, it probably requires a custom file-system implementation that needs maintaining across all operating systems that Postgres runs on. That's a major undertaking! -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest.
On 01/09/12 3:07 AM, Alban Hertroys wrote: >> For the record, it looks like MS SQL Server has some equivalent feature : >> > FILESTREAM. > And Oracle has BFILE. aren't these things functionally similar to PG's LO (large object) ? -- john r pierce N 37, W 122 santa cruz ca mid-left coast
On 9 January 2012 12:36, John R Pierce <pierce@hogranch.com> wrote: > On 01/09/12 3:07 AM, Alban Hertroys wrote: >>> >>> For the record, it looks like MS SQL Server has some equivalent feature : >>> > FILESTREAM. >> >> And Oracle has BFILE. > > aren't these things functionally similar to PG's LO (large object) ? Oracle has BLOBs and CLOBs as well. IIRC, BFILEs reference a file on the file-system, while [BC]LOBs are stored inside the database in some way. Admittedly, the last time I worked with an Oracle database is 10 years ago. Things may have changed, or my memory of them may have ;) -- If you can't see the forest for the trees, Cut the trees and you'll find there is no forest.
On Jan 9, 2012, at 5:07 AM, Alban Hertroys wrote: > On 9 January 2012 09:56, Damiano ALBANI >>> I believe DB2 is pretty much it in this area. >> >> For the record, it looks like MS SQL Server has some equivalent feature : >> FILESTREAM. > > And Oracle has BFILE. > > I've actually been thinking about how to implement something like this > for Postgres, but the interaction with the file-system makes it a > little more difficult to implement. Someone shouldn't be able to > delete a file from the file-system that's still referenced from the > database. > Perhaps a file-system layer with FusionFS would be a suitable solution > for something like this, but I couldn't convince myself that it is. > > In the end, it probably requires a custom file-system implementation > that needs maintaining across all operating systems that Postgres runs > on. That's a major undertaking! > -- > If you can't see the forest for the trees, > Cut the trees and you'll see there is no forest. > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general Not sure I see the need to keep the user/system from deleting a database referenced file. BFILEs are created completelyoutside of Oracle and Oracle will not insert data or write to a BFILE. It seems the reference to the externalfile is a very weak read only reference as BFILE provides functions like fileExists() and isFileOpen(). They leaveit up to the code to determine if the file is available and has the correct permisisons.