Re: #define ExclusiveLock in /usr/include/postgresql/9.1/server/storage/lock.h

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Arturas Mazeika <mazeika(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: #define ExclusiveLock in /usr/include/postgresql/9.1/server/storage/lock.h
Date: 2013-10-11 16:05:19
Message-ID: 3528.1381507519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Arturas Mazeika <mazeika(at)gmail(dot)com> writes:
> I would like to express my wonder to see the following line

> #define ExclusiveLock 7 /* blocks ROW
> SHARE/SELECT...FOR

> (line number 543) in /usr/include/postgresql/9.1/server/storage/lock.h
> file, because ExclusiveLock is a name of a class in libspatialindex library
> (see* *libspatialindex.github.io).

That seems like an awfully strange name for a class ...

> I suppose changing the define to be all capital letters becomes a huge
> problem, doesn't it ?

ExclusiveLock has been defined, with that name, in the Postgres code for
close to 20 years, and there are many references to it both in the core
code and add-ons. Yes, changing it would be painful.

More generally, we can never promise not to conflict with any identifiers
defined in third-party code. I don't see any strong reason why we should
do something about this particular case.

I'd suggest arranging your code so that the stuff that deals with
libspatialindex can be in a file separate from code that needs to
know about Postgres internals. Then you could avoid #include'ing
the conflicting headers in the same source file.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2013-10-11 16:11:53 Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation
Previous Message Peter Eisentraut 2013-10-11 15:41:16 Re: pg_stat_statements: calls under-estimation propagation