| From: | Ian Grant <I(dot)A(dot)N(dot)Grant(at)damtp(dot)cam(dot)ac(dot)uk> |
|---|---|
| To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
| Cc: | Ian Grant <I(dot)A(dot)N(dot)Grant(at)damtp(dot)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] Backend problem with large objects |
| Date: | 1999-02-02 20:43:44 |
| Message-ID: | Pine.OSF.3.96.990202203715.13580A-100000@hotei.amtp.cam.ac.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2 Feb 1999, Tatsuo Ishii wrote:
> Reproduced here too. Seems very old and known problem of large object
> (writing into in the middle of a large object does not work).
Many thanks, does this mean it's not likely to be fixed? If so I'll take
this to the documentation list, if there is one. But first, can anyone
explain what *is* allowed in lo_write after lo_lseek? Is it OK to
overwrite a large object for example?
I also note that there is no way to truncate a large object without
reading the beginning bit and copying it out to another new large object,
which involves it going down the wire to the client and then back again.
Are there any plans to implement lo_trunc or something? Perhaps this is
difficult for the same reason lo_write is difficult inside a large object.
Ian
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sebestyen Zoltan | 1999-02-02 21:48:29 | |
| Previous Message | Bruce Momjian | 1999-02-02 20:39:51 | Re: [HACKERS] Optimizer speed and GEQO (was: nested loops in joins) |