Re: Time to drop old-style (V0) functions?
От | Andres Freund |
---|---|
Тема | Re: Time to drop old-style (V0) functions? |
Дата | |
Msg-id | 20161208225358.7gllyoyclo2ywk3m@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Time to drop old-style (V0) functions? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Time to drop old-style (V0) functions?
Re: Time to drop old-style (V0) functions? Re: [HACKERS] Time to drop old-style (V0) functions? Re: [HACKERS] Time to drop old-style (V0) functions? Re: [HACKERS] Time to drop old-style (V0) functions? |
Список | pgsql-hackers |
On 2016-12-08 17:38:38 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I'm wondering if it's not time for $subject: > > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > > forgotten > > - They have us keep weird hacks around just for the sake of testing V0 > > - they actually cost performance, because we have to zero initialize Datums, even if > > the corresponding isnull marker is set. > > - they allow to call arbitrary functions pretty easily > > If by the first point you mean "assume V1 when no info function is found", > I object to that. If you mean you want to require an info function, that > might be OK. I mean throwing an error. Silently assuming V1 seems like a horrible idea to me. It doesn't seem unlikely that we want to introduce a new call interface at some point given the runtime cost of the current one, and that'd just bring back the current problem. > The habit of zero-initializing Datums has got exactly nothing to do with > V0 functions; it's about ensuring consistent results and avoiding > heisenbugs from use of uninitialized memory. I do not think we should > drop it. Well, V0 functions don't have a real way to get information about NULL, and we allow non-strict V0 functions, so? Regards, Andres
В списке pgsql-hackers по дате отправления: