Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co |
Дата | |
Msg-id | 25024.1461765226@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's
bool-returning SQL functions to V1 call co
Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > Let's add a GUC allow_oldstyle_functions with a default of off, and > make fetch_finfo_record() throw an ERROR in the infofunc == NULL case > unless allow_oldstyle_functions = on. This is not about "V0 calling convention is awful". It isn't, really, unless you need to deal with nulls. This is about "allowing the finfo record to be missing is error-prone". What about inventing a PG_FUNCTION_INFO_V0() macro, and then defining the new GUC as "must find a matching finfo record"? That would present less conversion work for people who still have V0-style functions (and I'm sure there are more than a few of them out there). Now, if VS2015 actually has broken bool-returning V0, the argument for keeping it going becomes a lot weaker. But at this point I suspect strongly that that's not what happened but rather we've got a faulty bool cast there, which if true is something we need to fix regardless of any considerations about V0. Would someone please try the experiment requested upthread? regards, tom lane
В списке pgsql-hackers по дате отправления: