Thread: obsolete code
fmgr.c contains this: /* * !!! OLD INTERFACE !!! * * fmgr() is the only remaining vestige of the old-style caller support *functions. It's no longer used anywhere in the Postgres distribution, * but we should leave it around for a releaseor two to ease the transition * for user-supplied C functions. OidFunctionCallN() replaces it for new * code. * * DEPRECATED, DO NOT USE IN NEW CODE */ which git tells me dates from: 48165ec2 ( Tom Lane 2000-06-05 07:29:25 +0000 2080) Should we just drop all support for the old interface now? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> fmgr.c contains this:
> * DEPRECATED, DO NOT USE IN NEW CODE
> Should we just drop all support for the old interface now?
Is there any actual benefit to removing it? I don't recall that
it's been the source of any maintenance burden. I'd be fine with
dropping it if it were costing us something measurable, but ...
regards, tom lane
On 02/01/2013 10:38 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> fmgr.c contains this: >> * DEPRECATED, DO NOT USE IN NEW CODE >> Should we just drop all support for the old interface now? > Is there any actual benefit to removing it? I don't recall that > it's been the source of any maintenance burden. I'd be fine with > dropping it if it were costing us something measurable, but ... > > 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). cheers andrew
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
2013/2/1 Andrew Dunstan <andrew@dunslane.net>: > > On 02/01/2013 10:38 AM, Tom Lane wrote: >> >> Andrew Dunstan <andrew@dunslane.net> writes: >>> >>> fmgr.c contains this: >>> * DEPRECATED, DO NOT USE IN NEW CODE >>> Should we just drop all support for the old interface now? >> >> Is there any actual benefit to removing it? I don't recall that >> it's been the source of any maintenance burden. I'd be fine with >> dropping it if it were costing us something measurable, but ... >> >> > > > > My hope was that if we got rid of the old stuff we wouldn't need to use > > PG_FUNCTION_INFO_V1(myfunc); > removing function descriptor should not be good idea - it can be used for some annotation. I had a similar issue - and can be nice, if it is solved with some assertions. Regards Pavel > > > in external modules any more (I recently got bitten through forgetting this > and it cost me an hour or two). > > cheers > > andrew > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
2013/2/1 Tom Lane <tgl@sss.pgh.pa.us>: > 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. I like this idea, 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
2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>: > 2013/2/1 Tom Lane <tgl@sss.pgh.pa.us>: >> 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. > > 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
* Pavel Stehule (pavel.stehule@gmail.com) wrote:
> 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
No, I don't think we need or want to continue to support such an ugly,
ugly, hack.
+1 for adding a V0 and requiring it.
Thanks,
Stephen
On 02/01/2013 11:20 AM, Tom Lane wrote: > 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. Sounds like a good plan. cheers andrew
On 2/1/13 11:06 AM, Andrew Dunstan wrote: > 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 My fear with that would be that people would start forgetting this and modules won't work with older PG versions anymore.