Marko Kreen writes:
> On Thu, Jun 2, 2011 at 7:20 PM, Andrew Dunstan wrote:
>> Then maybe we need to use "#ifndef WIN32" in those places. That's what we do
>> for similar cases.
> No, that would be a bad idea - uglifies code for no good reason.
> The function is referenced undef IS_AF_UNIX() ch
On Thu, Jun 2, 2011 at 7:31 PM, Alvaro Herrera
wrote:
> Excerpts from Andrew Dunstan's message of jue jun 02 11:59:02 -0400 2011:
>> On 06/02/2011 11:29 AM, Marko Kreen wrote:
>> > As there was no going back now, I even touched msvc.pm.
>>
>> Why? Windows doesn't have Unix domain sockets at all.
>
On Thu, Jun 2, 2011 at 7:44 PM, Tom Lane wrote:
> Marko Kreen writes:
>> On Thu, Jun 2, 2011 at 7:20 PM, Andrew Dunstan wrote:
>>> Then maybe we need to use "#ifndef WIN32" in those places. That's what we do
>>> for similar cases.
>
>> No, that would be a bad idea - uglifies code for no good rea
Excerpts from Marko Kreen's message of jue jun 02 12:45:04 -0400 2011:
> On Thu, Jun 2, 2011 at 7:31 PM, Alvaro Herrera
> wrote:
> > Excerpts from Andrew Dunstan's message of jue jun 02 11:59:02 -0400 2011:
> >> On 06/02/2011 11:29 AM, Marko Kreen wrote:
> >> > As there was no going back now, I ev
Excerpts from Andrew Dunstan's message of jue jun 02 11:59:02 -0400 2011:
>
> On 06/02/2011 11:29 AM, Marko Kreen wrote:
> >
> > As there was no going back now, I even touched msvc.pm.
>
> Why? Windows doesn't have Unix domain sockets at all.
So much for being thorough :-P
--
Álvaro Herrera
T
On 06/02/2011 01:04 PM, Alvaro Herrera wrote:
Excerpts from Marko Kreen's message of jue jun 02 12:45:04 -0400 2011:
On Thu, Jun 2, 2011 at 7:31 PM, Alvaro Herrera
wrote:
Excerpts from Andrew Dunstan's message of jue jun 02 11:59:02 -0400 2011:
On 06/02/2011 11:29 AM, Marko Kreen wrote:
A
Marko Kreen writes:
>> -1 ... why would you think that a conditional substitution is trouble?
>> We have plenty of others.
> Because it required touching autoconf. ;)
> So now I did it. I hope it was that simple.
Applied with minor adjustments --- notably, I didn't agree with removing
the speci
On Thu, Jun 2, 2011 at 6:59 PM, Andrew Dunstan wrote:
> On 06/02/2011 11:29 AM, Marko Kreen wrote:
>> As there was no going back now, I even touched msvc.pm.
>
> Why? Windows doesn't have Unix domain sockets at all.
Because the function is still referenced in the code.
--
marko
--
Sent via pg
On Thu, Jun 2, 2011 at 7:20 PM, Andrew Dunstan wrote:
> On 06/02/2011 12:04 PM, Marko Kreen wrote:
>> On Thu, Jun 2, 2011 at 6:59 PM, Andrew Dunstan
>> wrote:
>>> On 06/02/2011 11:29 AM, Marko Kreen wrote:
As there was no going back now, I even touched msvc.pm.
>>>
>>> Why? Windows doesn't h
Andrew Dunstan writes:
> On 06/02/2011 12:04 PM, Marko Kreen wrote:
>> On Thu, Jun 2, 2011 at 6:59 PM, Andrew Dunstan wrote:
>>> On 06/02/2011 11:29 AM, Marko Kreen wrote:
As there was no going back now, I even touched msvc.pm.
>>> Why? Windows doesn't have Unix domain sockets at all.
>> Bec
On 06/02/2011 12:04 PM, Marko Kreen wrote:
On Thu, Jun 2, 2011 at 6:59 PM, Andrew Dunstan wrote:
On 06/02/2011 11:29 AM, Marko Kreen wrote:
As there was no going back now, I even touched msvc.pm.
Why? Windows doesn't have Unix domain sockets at all.
Because the function is still referenced
On 06/02/2011 11:29 AM, Marko Kreen wrote:
As there was no going back now, I even touched msvc.pm.
Why? Windows doesn't have Unix domain sockets at all.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On Thu, Jun 2, 2011 at 5:49 PM, Tom Lane wrote:
> Marko Kreen writes:
>> Here's my attempt for it. As conditional port module seems trouble,
>> I set up an unconditional pgGetpeereid() that is always defined.
>
> -1 ... why would you think that a conditional substitution is trouble?
> We have pl
On Wed, Jun 1, 2011 at 1:03 AM, Tom Lane wrote:
> Marko Kreen writes:
>> 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.
>
> Hm, maybe. I'd be for this if we had more
Marko Kreen writes:
> Here's my attempt for it. As conditional port module seems trouble,
> I set up an unconditional pgGetpeereid() that is always defined.
-1 ... why would you think that a conditional substitution is trouble?
We have plenty of others.
regards, tom lane
On Wed, Jun 1, 2011 at 1:03 AM, Tom Lane wrote:
> Marko Kreen writes:
>> 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.
>
> Hm, maybe. I'd be for this if we had more
2011/5/31, Tom Lane :
> Unless maybe there's a kFreeBSD-like project out there with NetBSD as
> the kernel?)
There used to be an attempt by Debian (called GNU/NetBSD), but that
has since long been abandoned. I don't know of any other similar
projects.
http://www.debian.org/ports/netbsd/>
Wikipe
Marko Kreen writes:
> 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.
Hm, maybe. I'd be for this if we had more than two call sites, but
as things stand I'm not sure it'
On Wed, Jun 1, 2011 at 12:22 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut 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
Greg Stark writes:
> On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut 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
> s
On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut wrote:
>> So what I'm now thinking is we should rip out the control-message
>> implementation altogether, and instead use LOCAL_PEERCRED. This is
>> probably not something to back-patch, but it would make things a lot
>> cleaner going forward.
>
On tis, 2011-05-31 at 11:59 -0400, Tom Lane wrote:
> However, FreeBSD does have, and Debian/kFreeBSD does expose,
> getsockopt(LOCAL_PEERCRED), which turns out to be functionally
> equivalent to SO_PEERCRED: in particular, you can just call it and get
> the answer without having to fool with gettin
I wrote:
> BTW, after looking more closely at the buildfarm configure logs, it
> appears that both OpenBSD and NetBSD have getpeereid(), which means
> that they don't use this code at all. It is currently looking to me
> like the HAVE_STRUCT_FCRED and HAVE_STRUCT_SOCKCRED variants are dead
> code.
On 05/30/2011 07:57 PM, Tom Lane wrote:
I've applied patches to fix Martin Pitt's report of peer auth failing on
FreeBSD-amd64 kernels. I tested it with FreeBSD but do not have the
resources to check every other platform that uses the same code branch
in auth_peer. The buildfarm will soon tel
I wrote:
> I've applied patches to fix Martin Pitt's report of peer auth failing on
> FreeBSD-amd64 kernels. I tested it with FreeBSD but do not have the
> resources to check every other platform that uses the same code branch
> in auth_peer. The buildfarm will soon tell us if the patches fail to
I've applied patches to fix Martin Pitt's report of peer auth failing on
FreeBSD-amd64 kernels. I tested it with FreeBSD but do not have the
resources to check every other platform that uses the same code branch
in auth_peer. The buildfarm will soon tell us if the patches fail to
compile anywhere
26 matches
Mail list logo
