This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Pavel Stehule wrote:
>
>
> >
> >"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/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
