Re: BLOBs etc
От | Kris Jurka |
---|---|
Тема | Re: BLOBs etc |
Дата | |
Msg-id | Pine.BSO.4.56.0501070358040.5420@leary.csoft.net обсуждение исходный текст |
Ответ на | BLOBs etc (Sven Köhler <skoehler@upb.de>) |
Ответы |
Re: BLOBs etc
|
Список | 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 по дате отправления: