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
