On Wed, Jun 1, 2011 at 12:22 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <gsst...@mit.edu> writes: >> On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut <pete...@gmx.net> wrote: >>> Oh yes, no point in having complicated code that doesn't get exercised. > >> This does amount to desupporting old versions of those OSes in newer >> versions of Postgres, at least for this one feature. Since you're >> saying you don't want to backport it that doesn't seem like a big deal >> to me. Probably something worth mentioning in release notes though. > > Yeah, possibly. So far as I can tell, both FreeBSD and OpenBSD have had > getpeereid for so long that it couldn't be an issue. I guess there > might still be some people running pre-5.0 versions of NetBSD though. > > (BTW, in both FreeBSD and NetBSD, it turns out that getpeereid is just a > thin wrapper around SO_PEERCRED-equivalent getsockopt calls. However, > there doesn't seem to be any point in supporting NetBSD's getsockopt > call directly, because it was added at the same time as the getpeereid > function. Unless maybe there's a kFreeBSD-like project out there with > NetBSD as the kernel?)
My suggestion would be to use getpeereid() everywhere. And just have compat getpeereid() implementation on non-BSD platforms. This would minimize ifdeffery in core core. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
