Skip site navigation (1) Skip section navigation (2)

Re: SPI-header-files safe for C++-compiler

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Jacob Rief <jacob(dot)rief(at)gmx(dot)at>, pgsql-patches(at)postgresql(dot)org, andrew(at)dunslane(dot)net
Subject: Re: SPI-header-files safe for C++-compiler
Date: 2007-06-29 20:37:29
Message-ID: 8270.1183149449@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

pgsql-patches by date

Next:From: Kevin GrittnerDate: 2007-06-29 21:43:14
Subject: Warm standby patch
Previous:From: Heikki LinnakangasDate: 2007-06-29 20:31:29
Subject: Checkpoint logging, revised patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group