Re: Question about todo item

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about todo item
Date: 2001-08-05 03:34:13
Message-ID: 200108050334.f753YDN09213@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I keep bugging Jan about it, since pre-7.1 and no one has come up with
> > an idea.
>
> Well, if you want an idea:
>
> BEGIN;
>
> SELECT open_toast_object(toastable_column) FROM tab WHERE ...;
>
> -- app checks that it got exactly one result back
>
> -- app lo_reads and/or lo_writes using ID returned by SELECT
>
> END;
>
> Implementation is left as an exercise for the reader ;-).
>
> Offhand this seems like it would be doable for a column-value that
> was actually moved out-of-line by TOAST, since the open_toast_object
> function could see and return the TOAST pointer, and then the read/
> write operations just hack on rows in pg_largeobject. The hard part

I am confused how pg_largeobject is involved?

> is how to provide equivalent functionality (transparent to the client
> of course) when the particular value you select has *not* been moved
> out-of-line. Ideas anyone?

Don't forget compression of TOAST columns. How do you fseek/read/write
in there?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-05 03:55:24 Re: Question about todo item
Previous Message Tom Lane 2001-08-05 03:11:39 Re: Question about todo item