Re: BLOBs etc - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: BLOBs etc
Date
Msg-id Pine.BSO.4.56.0501070358040.5420@leary.csoft.net
Whole thread Raw
In response to BLOBs etc  (Sven Köhler <skoehler@upb.de>)
Responses Re: BLOBs etc  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-jdbc

On Fri, 7 Jan 2005, Thomas Hallgren wrote:

> Kris Jurka wrote:
> > That would work, but it's not going to happen.  Setting up and using a
> > large object is completely different than just stashing data in a bytea
> > field.  Convincing the server to do simple conversions is difficult
> > enough, getting it to do something of this magnitude is out of the
> > question.
> >
> Why? After all, both types represent a sequence of bytes so it's not
> really doing a conversion. It's just allowing multiple ways of accessing it.
>
> I'm not sure it would be that much work to actaully make the server
> accept both "by value" and "by stream" semantics for both types.
> Implemented correctly, all clients (not just JDBC) could benefit.
>

I'm not clear what your advocating in concrete terms.  A new pseudo type
"binary data" that could be used until it needs to convert it into a
concrete type?  When does this conversion have to happen?  Consider cases
like:

SELECT ? = ?;

SELECT myfunc(?);

INSERT INTO mytab SELECT * FROM (SELECT 1 UNION SELECT 2) t1(a) LEFT
JOIN (SELECT 1, ?) t2(a) on (t1.a = t2.a);


In the abstract, sure they're both just streams of bytes, but I think when
you have to actually handle this in the server you'll find they are not so
similar.

Note also that when streaming a large object to the server, you are
streaming it directly into permanent storage a chunk at a time so not much
memory is used.  If you don't know where it is going you can't stream it
to it's destination and you've got to either put it into a temporary disk
location or keep it in memory.

Kris Jurka

pgsql-jdbc by date:

Previous
From: solar solar
Date:
Subject: unsubscribe
Next
From: Thomas Hallgren
Date:
Subject: Re: BLOBs etc