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

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

From

Arturas Mazeika

Date:

11 October 2013, 16:49:17

Hi pg_Hackers,

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).

Using postgres SPI and the spatial library becomes quite a challenge in a larger project, since the order of the includes starts making a big difference. Suddenly the c++ pre-processor starts generating codes like

    class 7
    {

     }

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

Cheers,
arturas

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 12.04.2 LTS
Release:    12.04
Codename:    precise

$ psql -c 'select version()'
                                                  version
------------------------------------------------------------------------------------------------------------
PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
(1 row)

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

From

Tom Lane

Date:

11 October 2013, 19:05:27

Arturas Mazeika <mazeika@gmail.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