Re: [PATCHES] plpgsql, return can contains any expression
От | Pavel Stehule |
---|---|
Тема | Re: [PATCHES] plpgsql, return can contains any expression |
Дата | |
Msg-id | BAY114-F21BB578F2FA3B0B772FFA2F92E0@phx.gbl обсуждение исходный текст |
Ответ на | Re: [PATCHES] plpgsql, return can contains any expression (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] plpgsql, return can contains any
Re: [PATCHES] plpgsql, return can contains any expression |
Список | pgsql-hackers |
> >"Pavel Stehule" <pavel.stehule@hotmail.com> writes: > >> This patch doesn't seem to cope with cases where the supplied tuple has > >> the wrong number of columns, and it doesn't look like it's being >careful > >> about dropped columns either. Also, that's a mighty bizarre-looking > >> choice of cache memory context in coerce_to_tuple ... but then again, > >> why are you bothering with a cache at all for temporary arrays? > > > I am sorry, Tom. But I don't understand. I can check number of columns, > > ofcourse and I'll do it. What cache for temporary arrays do you mean? > >I thought that making coerce_to_tuple depend on estate->err_func was >pretty bizarre, and that there was no need for any "cache" at all for >arrays that need only live as long as the function runs. All you are >saving here is a palloc/pfree cycle, which is not worth the obscurantism >and risk of bugs (are you sure natts can never change?). No, cache there is ugly. But I don't have idea about more efective implementation of it :-(. First version of this patch was more clean. and little bit slow. This cache save 10%. > >BTW, if you want this patch to make it into 8.2, it needs to be fixed >and resubmitted *very* soon. I understand, but I am not able work on it in next four days. And I need help with it from Neil. It will be for 8.3. Thank you Pavel _________________________________________________________________ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/
В списке pgsql-hackers по дате отправления: