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

On Tue, Apr 26, 2016 at 10:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I don't understand why we don't just drop V0. It makes debugging harder,
>> exploitation easier (call arbitrary functions), and really has no
>> features making it desirable.
>
> What's the argument that it makes debugging harder? Especially if
> you aren't using it?
>
> I don't particularly buy the "easier exploitation" argument, either.
> You can't create a C function without superuser, and if you've got
> superuser there are plenty of ways to run arbitrary code.
>
> I'd agree that there are no desirable features that would motivate
> writing new code in V0. But that's not the reason for keeping it;
> the reason for keeping it is to avoid unnecessarily breaking
> existing extension code.

I don't think that argument holds much water any more. The V1
interface was added in 0a7fb4e9184539afcb6fed0f1d2bc0abddc2b0a6, more
than 15 years ago. Anybody who has extension code that old that still
does anything useful and hasn't needed much bigger changes that
conversion to V1 calling convention deserves a medal. But more than
that, it's unreasonable to expect 15-year-plus deprecation windows for
features that are only exposed via C. If we stuck to that rigidly it
would be a major impediment to forward progress.

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. That way, anybody who still
really wants to use V0 can do so. For everybody else, the very first
attempt to execute a function where you've forgotten or fat-fingered
the PG_FUNCTION_INFO_V1 decoration will produce a clear error message
telling you exactly what you did wrong. I confidently predict a lot
more people will be happy about that development than will be sad
about having to set a GUC to make their V0 functions work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company