I really don't know. JDBC communication is being handled by a JDO library, so I don't know which one is doing this, but I suspect about JDO. I feel like asking about it in the forums there, but then I'd like to know: is there any performance (disk, read/write speed...) difference between storing large text data as TEXT and large object? I believe this indirection of storing as large object could mean a small overhead, unless it is somehow better using large objects (just then why use TEXT for some data that is just a couple of chars?)
Thanks again!
On Fri, Oct 2, 2009 at 5:35 AM, Raymond O'Donnell
<rod@iol.ie> wrote:
On 01/10/2009 13:24, mad rug wrote:
> CREATE TABLE "ABC" (
> "DT" date NOT NULL,
> "TXT" text NOT NULL
> );
> INSERT INTO "ABC" VALUES ('2009-07-27', '44828');
> SET search_path = pg_catalog;
> SELECT lo_open(lo_create(44828), 131072);
> SELECT lowrite(0, 'all my text is here');
> SELECT lo_close(0);
> COMMIT;
>
> This seems to indicate that it is really some id being stored in that
> column. I could correctly query the column data with this command:
> SELECT "DT",loread(lo_open("TXT"::int, 131072), 999999999) from "ABC"
Actually, your text data is apparently being stored as large objects,
rather than being inserted directly into the text column. So it may
indeed be JDBC doing something funny.
I don't know anything about JDBC or PG's large objects (and not a whole
lot about Java either), but I wonder if something is telling JDBC that
the data is binary, rather than just plain text?
Ray.
------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie Galway Cathedral Recitals:
http://www.galwaycathedral.org/recitals ------------------------------------------------------------------