From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:20:39 |
Message-ID: | 15765.1359735639@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2013-02-01 16:21:40 | Re: obsolete code |
Previous Message | Alvaro Herrera | 2013-02-01 16:19:26 | Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system |