Neil Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
