Re: Coping with 'C' vs 'newC' function language names
От | Bruce Momjian |
---|---|
Тема | Re: Coping with 'C' vs 'newC' function language names |
Дата | |
Msg-id | 200011171734.MAA26108@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Coping with 'C' vs 'newC' function language names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Coping with 'C' vs 'newC' function language names
Re: Coping with 'C' vs 'newC' function language names |
Список | pgsql-hackers |
> 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? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: