Tom Lane <t...@sss.pgh.pa.us> writes: > "Dag-Erling Smørgrav" <d...@des.no> writes: > > 1. PostgreSQL's private versions of inet_aton etc. can conflict with > > similar functions in other libraries (in my case, PostgreSQL's > > inet_aton conflicts with libavformat's). > So what? We don't link with those libraries.
Your users might need to link with both. I'm working on an application that generates animations (specifically, animated weather forecasts) based on data retrieved from a PostgreSQL database. > The proposed #defines seem like a completely bad idea, especially > since as-presented they would affect every platform not only yours. Yes. That's the idea. This is a common idiom - the canonical way, if you will, of solving this problem, which is not exclusive to PostgreSQL. There are even cases in which you have no other choice, e.g. when the function you want to use is available but does not work properly or does not implement a particular feature that you need. > We don't need the maintenance/debugging headaches of routines that > don't have the names they appear to have. Honestly, I don't see the problem. > > ifeq ($(PORTNAME),win32) > > -LIBS += -lws2_32 -lshfolder > > +LIBS += -lws2_32 -lshfolder -lsecur32 > > endif > Surely this bit would need to be conditional on whether libsecur32 > is available? It's just as much part of Win32 as ws2_32 (winsock). DES -- Dag-Erling Smørgrav - d...@des.no -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
