On Tue, May 11, 2010 at 1:08 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On m=E5n, 2010-05-10 at 15:55 +0000, Bryan Henderson wrote:
>> >>> I don't know how concrete you want.
>> >
>> >Something one can download and compile.
>>
>> That wouldn't be worth anyone's effort, since the problem is esaily
>> enough elucidated with a few words of explanation. =A0I.e. I'm sure you
>> can imagine writing a program that would demonstrate the problem of
>> two header files that both typedef "bool".
>
> Sure I can fabricate code that fails, but that wouldn't necessarily be
> worth fixing, because it's fabricated and doesn't address anyone's real
> problems.
>
> We could try to make this work, but we're probably not going to rename
> our bool type, so we'll have to work out some reasonable workaround.
> But that's hard to do without having some practical example to work
> with.
Just to be clear, we wouldn't need to rename the type at the SQL level
- Catalog.pm can cope with mapping a C type name onto a different SQL
type name. You probably knew that already, but...
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.
On the flip side if the code that purports to cope with other
definitions of bool is useless, we should remove it so as to avoid
giving the impression that we have any ability to so cope.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company