On Wed, Jun 1, 2011 at 12:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut <peter_e(at)gmx(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-05-31 21:54:38|
|Subject: pgsql: Protect GIST logic that assumes penalty values can't benegative|
|Previous:||From: Cédric Villemain||Date: 2011-05-31 21:50:58|
|Subject: Re: Getting a bug tracker for the Postgres project|