Yes, I'll go for pure TEXT objects. I read this performance tip about TEXT
on the docs, makes me like Postgres :-)Anyway, I just checked alternative
types for character data, and tested JDBC type LONGVARCHAR, and now the data
is being stored directly to the TEXT field. Just configuration after all,
On 02/10/2009 12:55, mad rug wrote:
> 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/w
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
la
Well, all the data is inserted and used by JDBC (other libraries on top of
JDBC, in fact), and it is all working perfectly for months. I can update
and/or read data through JDBC or pgAdmin, and the change is correctly
reflected on the other.The first TEXT columns I used store text files around
50k,
mad rug wrote:
Yes, that's how Ray said.
"88352" is not the data I have in that entry, it is some plain text
data. This data can be quite large, so I use TEXT instead of CHAR/VARCHAR.
I'm puzzled how can this seem like some unusual situation... I thought
that it was the way pgAdmin returned
I have used text in all my tables in Postgres and have never had a problem
inserting data nor viewing it with PgAdmin. How do you know it isn't a JDBC
issue?
On Wed, Sep 30, 2009 at 3:48 PM, mad rug wrote:
> Yes, that's how Ray said.
>
> "88352" is not the data I have in that entry, it is some p
Yes, that's how Ray said.
"88352" is not the data I have in that entry, it is some plain text data.
This data can be quite large, so I use TEXT instead of CHAR/VARCHAR.
I'm puzzled how can this seem like some unusual situation... I thought that
it was the way pgAdmin returned large objects (to av
On 30/09/2009 21:28, Michael Shapiro wrote:
> What is wrong with these results? COL1 has the text value "88352"
I think his point was that this was what he got querying via pgAdmin,
while he got the actual column contents via JDBC.
Ray.
--
What is wrong with these results? COL1 has the text value "88352"
On Wed, Sep 30, 2009 at 2:52 PM, Dave Page wrote:
> [Please keep the list CC'd]
>
> On Wed, Sep 30, 2009 at 8:49 PM, mad rug wrote:
> > Hi
> >
> > This is the definition:
> >
> > CREATE TABLE "TBL"
> > (
> > "ID" bigint NOT NUL
[Please keep the list CC'd]
On Wed, Sep 30, 2009 at 8:49 PM, mad rug wrote:
> Hi
>
> This is the definition:
>
> CREATE TABLE "TBL"
> (
> "ID" bigint NOT NULL,
> "COL1" text NOT NULL,
> "COL2" integer NOT NULL,
> "COL3" character(2) NOT NULL,
> CONSTRAINT "TBL_pkey" PRIMARY KEY ("ID")
>
On Wed, Sep 30, 2009 at 8:40 PM, mad rug wrote:
> Hi
>
> This is a very simple question, but I couldn't google an answer.
> I have some tables with TEXT data type columns and my application can use
> them with no problem; just when I query these columns using pgAdmin, they
> show up as some int id
Hi
This is a very simple question, but I couldn't google an answer.
I have some tables with TEXT data type columns and my application can use
them with no problem; just when I query these columns using pgAdmin, they
show up as some int id. How can I view the actual column content?
I'm using pgAdmi
12 matches
Mail list logo
