obsolete code

Started by Andrew Dunstanalmost 13 years ago10 messages

andrew@dunslane.net

almost 13 years ago

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 release or 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane

tgl@sss.pgh.pa.us

almost 13 years ago

In reply to: Andrew Dunstan (#1)

Re: obsolete code

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan

andrew@dunslane.net

almost 13 years ago

In reply to: Tom Lane (#2)

Re: obsolete code

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane

tgl@sss.pgh.pa.us

almost 13 years ago

In reply to: Andrew Dunstan (#3)

Re: obsolete code

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

--
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

almost 13 years ago

In reply to: Andrew Dunstan (#3)

Re: obsolete code

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

--
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

almost 13 years ago

In reply to: Tom Lane (#4)

Re: obsolete code

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

--
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

almost 13 years ago

In reply to: Pavel Stehule (#6)

Re: obsolete code

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Stephen Frost

sfrost@snowman.net

almost 13 years ago

In reply to: Pavel Stehule (#7)

Re: obsolete code

* 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

Andrew Dunstan

andrew@dunslane.net

almost 13 years ago

In reply to: Tom Lane (#4)

Re: obsolete code

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#10

Peter Eisentraut

peter_e@gmx.net

almost 13 years ago

In reply to: Andrew Dunstan (#3)

Re: obsolete code

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers