Re: Question about todo item
От | Jan Wieck |
---|---|
Тема | Re: Question about todo item |
Дата | |
Msg-id | 200108061440.f76EeI607080@jupiter.us.greatbridge.com обсуждение исходный текст |
Ответ на | Re: Question about todo item (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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 > 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? TOAST values aren't stored in pg_largeobject. And how do you seek to a position in a compressed and then sliced object?We need a way to force the object over a streaming interface into uncompressed toast slices first. Let methink about it for two days, Okay? The interface lacks imho a mode (r/w/rw/a) argument. Other than that I'd like this part. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-hackers по дате отправления: