Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues - Mailing list pgsql-general

From Radosław Smogura
Subject Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues
Date
Msg-id 1472223.7TltgQ0Nt7@localhost
Whole thread Raw
In response to Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues  (Alban Hertroys <haramrae@gmail.com>)
Responses Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues  (Alban Hertroys <haramrae@gmail.com>)
Re: [JDBC] Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-general
Dnia poniedziałek, 9 stycznia 2012 o 15:52:23 Alban Hertroys napisał(a):
> On 9 January 2012 14:55, Radosław Smogura <rsmogura@softperience.eu> 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




pgsql-general by date:

Previous
From: Thomas Markus
Date:
Subject: Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues
Next
From: akp geek
Date:
Subject: queries timeout during backup postgres database