Re: BLOBs

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: Raw Message | Whole Thread | 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

In response to

  • Re: BLOBs at 2001-06-12 22:19:46 from Thomas Swan

Browse pgsql-hackers by date

  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