Hello, 2014-10-18 3:59 GMT+04:00 Stephen Woodbridge <wood...@swoodbridge.com>:
> Hi, > > I've been writing C++ code that needs to get wrapped into a postgresql > extension and it has a few singleton classes like: > > 1. Config object that holds some general configuration information. > 2. Stats object for global stats collection. > 3. Logger object for enabling/disabling debug logging to a file. > 4. curlpp class for making outbound calls to an OSRM web service from the > c++ code > > I can probably do without 1-3 if I had to when the code is integrated, but > they are handy to keep around in the code for when we are developing and > working outside the postgresql database. I could #ifdef then all, but I > would like to avoid cluttering the code with tons of #ifdef. > > Item 4 is a little more problematic and needs to be kept around or > something else implemented to take its place. I have looked at the curl > extension and actual built another module in C that uses those ideas., but > the curlpp is a nice OO class that encapsules and hides all the curl stuff > from the C++ code. > > So my question(s) are: > > 1. Any insights into singletons working/not working within the postgresql > server extensions? My understanding is that these are implemented as global > static classes with a lifetime of the process and they have no destructor, > so I'm a little worried about memory leaks or multiple queries sharing the > singleton. > > 2. Is there another way implement the equivalent of a singleton for C++ > code that has a lifetime of the query in the server? > > 3. What do for logging classes when integrating C++ code into postgresql? > > Any help or ideas would be appreciated. > I would have written extension in pure C. And I would get rid of singletones. (Singletone - artificial constraints that the programmer creates for himself. Btw, C++ - too :-) ) I would use Extension Configuration Tables to store the configuration http://www.postgresql.org/docs/9.4/static/extend-extensions.html#AEN57238 -- // Dmitriy.
