Search Postgresql Archives

Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dnia poniedziałek, 9 stycznia 2012 o 15:52:23 Alban Hertroys napisał(a):
> On 9 January 2012 14:55, Radosław Smogura <rsmogura@xxxxxxxxxxxxxxx> wrote:
> > So responsible for this is database, but database doesn't have
> > "real" BLOBs, this what is made in PG JDBC driver is just "not perfect"
> > way to add this functionality to PostgreSQL.
> 
> I think you should elaborate on what you mean when you say that
> Postgres doesn't have "real" BLOBs.
> 
> This discussion did make me wonder about something in Postgres'
> LOB-support though. As explained earlier, the current implementation
> allows for dedubbing LOB's, so that it's not necessary to store the
> same large(!) object multiple times. That is also what's causing this
> issue with the JDBC driver, or perhaps Hybernate in particular.
> 
> However, shouldn't it be up to the application designer to dedup large
> objects or not?
> 
> The current implementation is probably rather convenient for projects
> where duplicate large objects are common, but - as it turns out - it
> can be quite inconvenient when that's opposite to expectations.
> 
> ISTMT this behaviour should at least be optional. Of course that
> raises the question what should happen with an existing set of LOB's
> when that setting gets changed.
In real world BLOBs are transfered as references, and those references are 
managed in way as the trigger does. Nacked PG doesn't support deletion, Oid is 
universal type so it can't be used by GC approach, unles collector will know 
which Oid is LOB oid.

Oid is like void*, it's abstarct pointer. If you get void* you don't know if 
data referenced by it represent person row, or car row, you don't know if 
void* is even reference or just 64 bit number. Current implementation is not 
type safe. You can't just write UPDATE TABLE x SET blob = 'aadfasfasfda' which 
in current times should be supported, but you may write (if are not fully 
familiar with db) UPDATE table X set varchar_d = blob_column;

In fact LOB's id may be stored even as varchar. So true is that PG supports 
LOBs, but due to missing functionality LOBs are quite hard to manage. It's 
like car withot steering wheel - you may drive, but it's little bit hard.

Regards,
Radek




-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux