Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Define INADDR_NONE on Solaris when it's missing.

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Define INADDR_NONE on Solaris when it's missing.
Date: 2010-02-01 13:07:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
2010/1/28 Magnus Hagander <magnus(at)hagander(dot)net>:
> On Thu, Jan 28, 2010 at 21:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> On Thu, Jan 28, 2010 at 17:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> However, now that I know the real issue is you're using inet_addr, I
>>>> would like to know why you're not using inet_aton instead; or even
>>>> better, something that also copes with IPv6.
>>> "Path of least resistance?"
>>> Which method would you suggest?
>> I haven't actually read the RADIUS patch, but generally we rely on
>> pg_getaddrinfo_all to interpret strings representing IP addresses.
>> Is there a reason not to use that?
> I don't think so. I'll look it over.

Here's what I came up with. Works well on the platforms I've tried,
but I haven't tried on a non-ipv6 capable one yet (need to find one..)
I'll also remove the defines from solaris.h when applying it.

 Magnus Hagander

Attachment: radius_addr.patch
Description: application/octet-stream (5.6 KB)

In response to


pgsql-hackers by date

Next:From: Matteo BeccatiDate: 2010-02-01 13:36:21
Subject: Re: mailing list archiver chewing patches
Previous:From: Andrew DunstanDate: 2010-02-01 12:54:48
Subject: Re: odd output in initdb

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-02-01 13:40:28
Subject: pgsql: Revoke augmentation of WAL records for btree delete, per
Previous:From: Dave PageDate: 2010-02-01 11:43:04
Subject: stackbuilder - wizard: Fix some compiler warnings.

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group