Supporting SQL/MED DATALINK

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:

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.
What I'm most interested in are the "transaction" and "auto deletion of
unused file" features of DATALINK.
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 <http://technet.microsoft.com/en-us/library/bb933993.aspx&gt;.

--
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 completely outside of Oracle and Oracle will not insert data or write to a BFILE. It seems the reference to the external file is a very weak read only reference as BFILE provides functions like fileExists() and isFileOpen(). They leave it up to the code to determine if the file is available and has the correct permisisons.