В письме от 10 апреля 2018 08:55:52 пользователь David Steele написал: > On 1/25/18 12:27 PM, Nikolay Shaplov wrote: > > В письме от 25 января 2018 11:29:34 пользователь Tom Lane написал: > >> Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > >>> Tom Lane wrote: > >>>> Well, maybe the right answer is to address that. It's clear to me > >>>> why that would happen if we store these things as reloptions on the > >>>> toast table, but can't they be stored on the parent table? > >>> > >>> Actually, Nikolay provided a possible solution: if you execute ALTER > >>> TABLE SET (toast.foobar = xyz), and a toast table doesn't exist, create > >>> one at that point. > >> > >> That adds a lot of overhead if you never actually need the toast table. > > > > I think this overhead case is not that terrible if it is properly warned > > ;-)> > >> Still, maybe it's an appropriate amount of effort compared to the size > >> of the use-case for this. > > > > If you came to some final conclustion, please close the commiffest item > > with "Return with feedback" resolution, and I write another patch... > > I think this patch should be marked Returned with Feedback since it > appears there is no consensus on whether it is useful or correct, so I > have done that. Exactly!
But I'd like to know what kind of feedback is it :-) What conclusion have been reached (I did not got it) Otherwise I would not know how to rewrite this patch. I would suggest: create a TOAST relation whenever toast.* options is set, but give a warning it this relation will not be used for data storage (i.e. there is no toastable columns in the table) But I need some confirmation, in order not to write patch in vain again :-) > > If I got it wrong I'm happy to move it to the next CF in Waiting for > Author state instead. > > Thanks, -- Do code for fun.
signature.asc
Description: This is a digitally signed message part.
