Re: bool: symbol name collision - Mailing list pgsql-bugs

From Greg Stark
Subject Re: bool: symbol name collision
Date
Msg-id AANLkTimCUXR6y3Red_Gx03Iwcw04-V5XMWbueRB-AN3J@mail.gmail.com
Whole thread Raw
In response to Re: bool: symbol name collision  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: bool: symbol name collision  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-bugs
On Tue, May 11, 2010 at 8:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alex Hunsaker <badalex@gmail.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. =A0A 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. =A0I 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.

--=20
greg

pgsql-bugs by date:

Previous
From: Koichi Suzuki
Date:
Subject: Bug-fix and new feature of pg_lesslog is released
Next
From: Peter Eisentraut
Date:
Subject: Re: bool: symbol name collision