Re: obsolete code

2013/2/1 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2013/2/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Andrew Dunstan <andrew(at)dunslane(dot)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.
>
> I like this idea,
>

but some users uses V0 for glibc functions - it is probably ugly hack,
but it allows using external libraries - and should be possible still
use it

Regards

Pavel

> Pavel
>
>>
>> regards, tom lane
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers