Re: Should contrib modules install .h files?
От | Andrew Gierth |
---|---|
Тема | Re: Should contrib modules install .h files? |
Дата | |
Msg-id | 87k1q8kokq.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Should contrib modules install .h files? (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Should contrib modules install .h files?
|
Список | pgsql-hackers |
>>>>> "Peter" == Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 02.07.18 15:26, Tom Lane wrote: >> FWIW, I agree with Andres' thought that each contrib module should >> have its own subdirectory under $(includedir_server). Otherwise >> we're going to be faced with questions about whether .h files need >> to be renamed because they're not globally unique enough. Peter> Then they perhaps should be renamed. That seems like a much Peter> simpler solution. Personally I think that more -I options is less pain than having to rename things or deal with conflicts. Where exactly are you suggesting that they should be installed? Directly in $(installdir_server), or in $(installdir_server)/extension or equivalent? Peter> The use case being discussed here is installing a data type Peter> extension's header so you can write a transform for it. The Peter> extension's name as well as the data type's own name already Peter> have to be pretty much globally unique if you want it to be Peter> useful. So it doesn't seem very difficult to me to have the Peter> extension install a single header file with that same name. That's assuming a single header file, which might be a bit more restrictive than absolutely necessary. Peter> The other side of this is that the PLs have to install their Peter> header files. Which the in-core PLs already do. Would we we want Peter> to move their header files under a new per-extension directory Peter> scheme? The in-core PLs could reasonably be grandfathered in in their current locations, at least for now. -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: