Re: libpq's pollution of application namespace - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: libpq's pollution of application namespace
Date
Msg-id 200606142154.k5ELsuq00583@candle.pha.pa.us
Whole thread Raw
In response to libpq's pollution of application namespace  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq's pollution of application namespace  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: libpq's pollution of application namespace  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Thread added to TODO:
       o Properly mark all libpq-exported functions with "PQ"


---------------------------------------------------------------------------

Tom Lane wrote:
> I find that libpq.so exports the following symbols that have neither
> PQ, pq, pg, nor lo_ as a prefix:
> 
> EncryptMD5
> SockAddr_cidr_mask
> fe_getauthname
> fe_getauthsvc
> fe_sendauth
> fe_setauthsvc
> freeaddrinfo_all
> getaddrinfo_all
> getnameinfo_all
> md5_hash
> rangeSockAddr
> 
> md5_hash seems a particularly unforgivable intrusion on application
> namespace :-(.  Any objection to fixing these things to be prefixed
> with pq or pg, which is the convention we usually follow for "internal"
> names that can't be static?
> 
> Also, these functions strictly speaking violate application namespace,
> but given that PQ appears infix, they're probably OK.
> 
> appendBinaryPQExpBuffer
> appendPQExpBuffer
> appendPQExpBufferChar
> appendPQExpBufferStr
> createPQExpBuffer
> destroyPQExpBuffer
> enlargePQExpBuffer
> initPQExpBuffer
> printfPQExpBuffer
> resetPQExpBuffer
> termPQExpBuffer
> 
> It'd be nicer if we could filter out all exported symbols that don't
> appear in exports.txt, but I don't know any portable way to do that.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches
Next
From: Josh Berkus
Date:
Subject: Re: Multi-byte and client side character encoding