Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co
Date
Msg-id 25024.1461765226@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co  (Robert Haas <robertmhaas@gmail.com>)
Responses 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
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.6 and fsync=off
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] Re: pgsql: Convert contrib/seg's bool-returning SQL functions to V1 call co