Re: Coping with 'C' vs 'newC' function language names
От | Hannu Krosing |
---|---|
Тема | Re: Coping with 'C' vs 'newC' function language names |
Дата | |
Msg-id | 3A15B4A0.508F0D7B@tm.ee обсуждение исходный текст |
Ответ на | Re: Coping with 'C' vs 'newC' function language names (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Coping with 'C' vs 'newC' function language names
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > I didn't want to do this during development, but now that there are no > > more old-style internal functions left, I suppose you could make a good > > argument that this is worth doing for old-style dynamically loaded > > functions. Will put it on the to-do list. > > > > Are people satisfied with the notion of requiring an info function > > to go with each dynamically loaded new-style function? If so, I'll > > start working on that too. > > I think we need to balance portability with inconvenence for new users. > > I think mixing new/old function types in the same object file is pretty > rare, and the confusion for programmers of having to label every > function seems much more error-prone. > > I would support a single symbol to mark the entire object file. In > fact, I would require old-style functions to add a symbol, and have > new-style functions left alone. > > There are not that many functions out there, are there? People are > having to recompile their C files anyway for the upgrade, don't they? Can't we insert that magic variable automatically using some #includ/#define tricks ? So that people need just to recompile, but the result has the variable nonetheless ? ----------- Hannu
В списке pgsql-hackers по дате отправления: