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 <r...@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
> r...@iol.ie
> Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
> ------------------------------------------------------------------
>
