Re: bool: symbol name collision

On Tue, May 11, 2010 at 8:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>
>> You mean i'd get the pleasure of 'fixing' all my 3rd party C modules?
>
> Yeah, it's the implications for 3rd-party modules that make me not want
> to do this.  A search & replace on our own code base is one thing, but
> when it's positively guaranteed to hit most add-on modules as well,
> you need to show a pretty strong benefit from it.  I think the argument
> for changing this is too thin to support that.

Well you could imagine doing this for all our types by doing:

search and replace int4 -> pgint4 etc.
add #ifndef int4 #define int4 pgint4 at the end of postgres.h

That way third-party apps which define their own int4 would be
required to use pgint4. But third-party apps which don't could
continue to use int4. All struct interfaces etc would be defined using
pgint4 directly so wouldn't be affected by any unusual definition of
int4.

The trick would be to ensure that nothing in the postgres interfaces
depend on the bool or int4 definitions. That would be easy to ensure
after the search/replace but hard to guarantee long-term.

--
greg