Lists: | pgsql-hackers |
---|
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | obsolete code |
Date: | 2013-02-01 13:44:34 |
Message-ID: | 510BC6C2.6020903@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
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 15:38:18 |
Message-ID: | 14763.1359733098@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:06:34 |
Message-ID: | 510BE80A.1060904@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 02/01/2013 10:38 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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
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 |
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: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:21:40 |
Message-ID: | CAFj8pRC9MguCS4sTm6DYz66L3z00M3txEEfmLbLSNQyTSQfKhA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2013/2/1 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
> On 02/01/2013 10:38 AM, Tom Lane wrote:
>>
>> Andrew Dunstan <andrew(at)dunslane(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:25:09 |
Message-ID: | CAFj8pRCyj+Hs+oRzGjggO2T0a5EotDfphv7g9qHJ1a_B_6-0eg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2013/2/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.
I like this idea,
Pavel
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:27:28 |
Message-ID: | CAFj8pRDWSLzpb7rOBakiPry15hJceM7f1irMN9HmONbh7Vvf4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
2013/2/1 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2013/2/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> 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.
>
> 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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:31:22 |
Message-ID: | 20130201163122.GB16126@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)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
From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 16:35:39 |
Message-ID: | 510BEEDB.2030103@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsolete code |
Date: | 2013-02-01 22:16:35 |
Message-ID: | 510C3EC3.1070509@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.