On Sun, 05 Jun 2011 22:16:41 +0200, Dimitri Fontaine wrote:
Tom Lane <t...@sss.pgh.pa.us> writes:
Yes. I think the appropriate problem statement is "provide
streaming
access to large field values, as an alternative to just
fetching/storing
the entire value at once". I see no good reason to import the
entire
messy notion of LOBS/CLOBS. (The fact that other databases have
done it
is not a good reason.)
Spent some time in the archive to confirm a certain “déjà vu”
impression. Couldn't find it. Had to manually search in closed
commit
fests… but here we are, I think:
https://commitfest.postgresql.org/action/patch_view?id=70
http://archives.postgresql.org/message-id/17891.1246301...@sss.pgh.pa.us
http://archives.postgresql.org/message-id/4a4bf87e.7010...@ak.jp.nec.com
Regards,
I think more about this with contrast to sent references, but I still
have in my mind construct
Blob myWeddingDvd = conn.createBlob(myWeddingStream, size); //A bit
outdated we have BlueRay
conn.prepareStatemnt("INSERT INTO someonetubevideos values (?)")
where 1st parameter is myWeddingDvd,
or if someone doesn't like Java he/she/it may wish to put C++ istream,
or C FILE.
I think (with respect to below consideration), this implicite requires
that LOBs should be stored in one, centralized place doesn't matter if
this will be file system or special table, or something else, but when
statement is processed there is no idea with which table LOB will be
associated, if we want to TOAST, where TOAST it, what will be if
insertion will by SQL function, which choose table depending on BLOB
content?
Quite interesting idea from cited patch was about string identifying
LOB, but with above it close road to for JDBC create LOB. I think, as
well constructs that insert 1st, small LOB into table to get some driver
depending API are little bit old fashioned.
Possible solutions, if we don't want centralized storage, may be:
1. Keep BLOB in memory, but this may, depending on implementation,
reduce size of initial BLOB.
2. Temporally backup blob in file, then when values are stored copy
file to TOAST table, but still some changes are required to support LOBs
for complex types and arrays.
So please give some ideas how to resolve this, or may be it has low
priority?
Regards,
Radek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
