Re: obsolete code
От | Pavel Stehule |
---|---|
Тема | Re: obsolete code |
Дата | |
Msg-id | CAFj8pRCyj+Hs+oRzGjggO2T0a5EotDfphv7g9qHJ1a_B_6-0eg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: obsolete code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: obsolete code
|
Список | 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
В списке pgsql-hackers по дате отправления: