From: | "Mitch Vincent" <mvincent(at)cablespeed(dot)com> |
---|---|
To: | "Steve Howe" <howe(at)carcass(dot)dhs(dot)org> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PQexec() 8191 bytes limit and text fields |
Date: | 2001-07-18 15:06:12 |
Message-ID: | 006901c10f9b$2f57b830$1251000a@Mitch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
First, are you using the latest PG? I was under the impression that all
the hard-coded limitations on size had been eliminated in the latest
releases. I know for an absolute fact that I can insert multi-megabyte sized
text chunks in PG 7.1.2 as I've done just that before...
Good luck!
-Mitch
----- Original Message -----
From: "Steve Howe" <howe(at)carcass(dot)dhs(dot)org>
To: <pgsql-hackers(at)postgresql(dot)org>
Sent: Wednesday, July 18, 2001 4:51 AM
Subject: [HACKERS] PQexec() 8191 bytes limit and text fields
> Hello all,
>
>
> Writing my interface application, which use the PQexec library, I
> came across the PQexec() queries 8191 bytes limit.
> What useful are 4Gb text fields if I have this limit ?
> I mean, if a user make an update to this field, with a large value
> (let's say, 4Mb), do I have to call PQexec multiple (more then 500) times,
> concatenating the strings each time I call it ??? Can't this be better
> implemented ? This is too slow, and generates much more traffic then I
ever
> wish.
> This problem also plagues the large objects API, since they're
only
> a wrapper to the built-in large objects API.
> Does anyone have a better way of doing this ?
>
> Best Regards,
> Steve Howe
> http://www.vitavoom.com
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-07-18 15:09:46 | Re: AW: Idea: recycle WAL segments, don't delete/recreate ' em |
Previous Message | Philip Warner | 2001-07-18 14:58:26 | Re: pg_depend |