Re: obsolete code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: obsolete code
Date
Msg-id 15765.1359735639@sss.pgh.pa.us
Whole thread Raw
In response to Re: obsolete code  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: obsolete code  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: obsolete code  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> My hope was that if we got rid of the old stuff we wouldn't need to use
>     PG_FUNCTION_INFO_V1(myfunc);
> in external modules any more (I recently got bitten through forgetting 
> this and it cost me an hour or two).

Oh.  Well, that's entirely unrelated to whether we leave fmgr() around.
fmgr() is the other end of the old call interface.

I'm not really thrilled with switching the default assumption to be V1,
especially not if we implement that by telling authors they can stop
bothering with the macros.  The pain will just come back sometime in the
future when we decide we need a function API V2.  (I'm actually a bit
surprised V1 has lived this long without changes.)

Here's a different straw-man proposal: let's start requiring *all*
external C functions to have an API-version block.  We can add a
PG_FUNCTION_INFO_V0(myfunc) macro for those people who are still using
V0 and don't feel like changing their code (and you know they're out
there).  For the rest of us, this would allow emitting an appropriate
error when we forget the macro.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system
Next
From: Pavel Stehule
Date:
Subject: Re: obsolete code