Re: bool: symbol name collision

On Tue, May 11, 2010 at 3:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>> On Tue, May 11, 2010 at 12:42, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I guess the question that comes to mind for me is how many other
>>> things fall into this category.  We define a lot of symbols like int4
>>> and int32 that other people could also have defined, and I don't
>>> really want to s/^/pg/ all of them.  If it's really only a question of
>>> renaming bool I could see doing it.
>
>> 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.

Yeah, that may well be. I don't think we should have a policy of
folding our arms and shouting "no" whenever someone asks us to clean
up our namespace, but on the flip side one request (or even two) is
probably not enough reason to do anything drastic, and this would be
fairly drastic. Aside from breaking third-party modules, it would
also create merge problems for pending patches and companies with
private forks of the code base, and, if aesthetics count for anything,
it would be sort of ugly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company