(2010/07/03 1:39), Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.
>>> Win32 never has HAVE_UNIX_SOCKET.
Peter Eisentraut wrote:
Is there any possibilities that both WIN32 and HAVE_UNIX_SOCKETS are
set concurrently? If possible, the libpq may try to call undefined
function, then build will be failed.
Win32 never has HAVE_UNIX_SOCKET.
Cygwin might though, I recall some old discussion about
On fre, 2010-07-02 at 09:16 +0100, Magnus Hagander wrote:
> On Fri, Jul 2, 2010 at 8:35 AM, KaiGai Kohei wrote:
> > (2010/07/01 11:30), Peter Eisentraut wrote:
> > I have a question.
> >
> > The pqGetpwuid() is enclosed by #ifndef WIN32 ... #endif, although
> > this patch encloses the section to o
On Fri, Jul 2, 2010 at 8:35 AM, KaiGai Kohei wrote:
> (2010/07/01 11:30), Peter Eisentraut wrote:
> I have a question.
>
> The pqGetpwuid() is enclosed by #ifndef WIN32 ... #endif, although
> this patch encloses the section to obtain user id of the peer by
> #ifdef HAVE_UNIX_SOCKETS ... #endif.
>
(2010/07/01 11:30), Peter Eisentraut wrote:
> On tis, 2010-06-22 at 09:37 +0900, KaiGai Kohei wrote:
>> As you described at the source code comments as follows,
>> it is not portable except for Linux due to the getsockopt() API.
>>
>> + // TODO: currently Linux-only code, needs to be
On tis, 2010-06-22 at 09:37 +0900, KaiGai Kohei wrote:
> As you described at the source code comments as follows,
> it is not portable except for Linux due to the getsockopt() API.
>
> + // TODO: currently Linux-only code, needs to be made
> + // portable; see backend/l
I've checked on this patch.
As you described at the source code comments as follows,
it is not portable except for Linux due to the getsockopt() API.
+ // TODO: currently Linux-only code, needs to be made
+ // portable; see backend/libpq/auth.c
I expect it shall be fi
On fre, 2010-06-11 at 08:07 -0400, Stephen Frost wrote:
> Having the option wouldn't do much unless users know of it and use it
> and it strikes that will very often not be the case.
That situation is the same as with SSL over TCP/IP with certificate
validation. I don't think we can make either o
(2010/06/11 21:11), Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote:
>>> I definitely like the idea but I dislike requiring the user to do
>>> something to implement it. Thinking about how packagers might want to
>>> use
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote:
> > I definitely like the idea but I dislike requiring the user to do
> > something to implement it. Thinking about how packagers might want to
> > use it, could we make it possible to build it de
On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> The patch needs some portability work and possible refactoring because
>> of that, but before I embark on that, comments on the concept?
>
> I definitely like the idea but I dislike requiring the u
* Peter Eisentraut (pete...@gmx.net) wrote:
> The patch needs some portability work and possible refactoring because
> of that, but before I embark on that, comments on the concept?
I definitely like the idea but I dislike requiring the user to do
something to implement it. Thinking about how pac
On Sun, May 30, 2010 at 13:00, Peter Eisentraut wrote:
> It has been discussed several times in the past that there is no way for
> a client to authenticate a server over Unix-domain sockets. So
> depending on circumstances, a local user could easily insert his own
> server and collect passwords
On Sun, May 30, 2010 at 13:00, Peter Eisentraut wrote:
> It has been discussed several times in the past that there is no way for
> a client to authenticate a server over Unix-domain sockets. So
> depending on circumstances, a local user could easily insert his own
> server and collect passwords
14 matches
Mail list logo
