Re: SPI-header-files safe for C++-compiler
От | Tom Lane |
---|---|
Тема | Re: SPI-header-files safe for C++-compiler |
Дата | |
Msg-id | 8270.1183149449@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SPI-header-files safe for C++-compiler (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: SPI-header-files safe for C++-compiler
|
Список | pgsql-patches |
Neil Conway <neilc@samurai.com> writes: > I don't see a reason to reject the patch. All the arguments about why > using C++ in the backend is ill-advised are well-taken, but the patch > does *not* require "making a real commitment to making C++ usable as a > backend extension language", it just obviates the need for some people > to patch the source. ... at the cost of forcing other people to patch their source. If this were just an internal backend change it'd be OK, but by definition the patch is changing APIs that third-party code may depend on. That's why I think there needs to be a stronger argument than "might as well do it", and that stronger argument has got to discuss whether we are really supporting C++ in the backend. There's also a slippery-slope problem: if we accept making these headers C++-clean, why not every other backend header? Once we buy into the principle, you can bet that we'll get requests to sanitize every header that's of any interest. So I'd want to see some estimate of how many changes that entails, not just fixing the set of things that spi.h depends on. regards, tom lane
В списке pgsql-patches по дате отправления: