Re: obsolete code

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

In response to

Responses

Browse pgsql-hackers by date

  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