| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Thomas Swan <tswan(at)olemiss(dot)edu> | 
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: BLOBs | 
| Date: | 2001-06-12 23:02:09 | 
| Message-ID: | 16259.992386929@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Thomas Swan <tswan(at)olemiss(dot)edu> writes:
> I think I missed what I was trying to say in my original statement.  I 
> think there's a way to use the existing API with performance benefits 
> left intact.
> Take for example the table :
> create table foo {
>     foo_id serial,
>     foo_name varchar(32),
>     foo_object BLOB,
> );
> On the insert statement "insert into foo (foo_name,foo_object) values 
> ('My Object','{some escaped arbitrary string of binary data}');", flush 
> the {some escaped arbitrary string of binary data} to disk as a 
> temporary file.  Then do the lo_import operation transparent to the user.
> On a select, do the same thing (transparently) and return the data back 
> to user.
> Personally, I like LO's being stored separately from the actual table.
I still think you've rediscovered TOAST.  How is this better than (or
even significantly different from) foo_object being a toastable bytea
column?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-06-12 23:07:03 | Re: Re: [JDBC] unlink large objects | 
| Previous Message | Reinoud van Leeuwen | 2001-06-12 22:59:23 | Re: AW: AW: Postgres Replication |