Re: #define ExclusiveLock in /usr/include/postgresql/9.1/server/storage/lock.h
От | Tom Lane |
---|---|
Тема | Re: #define ExclusiveLock in /usr/include/postgresql/9.1/server/storage/lock.h |
Дата | |
Msg-id | 3528.1381507519@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | #define ExclusiveLock in /usr/include/postgresql/9.1/server/storage/lock.h (Arturas Mazeika <mazeika@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: