2013/2/1 Pavel Stehule <pavel.steh...@gmail.com>: > 2013/2/1 Tom Lane <t...@sss.pgh.pa.us>: >> Andrew Dunstan <and...@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. > > 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@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers