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

Re: pgwin32_open returning EINVAL

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>,Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgwin32_open returning EINVAL
Date: 2007-11-28 16:20:46
Message-ID: 20071128162046.GB28988@svr2.hagander.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
> > On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
> > > Can we do something like this to report the Win32 error code so that the
> > > user has a higher chance of figuring out what's going on?

We already do something very similar to what you're donig in
backend/port/wni32/socket.c :: TranslateSocketError().

So I think it's a good idea to do it, yes.


> > The Windows API provides a way to get the error message associated
> > with the code. It seems it would be more user-friendly if the message
> > was displayed (just as for unix) rather than the code.
> 
> Yeah, I looked into that (it's FormatMessage) but it's sufficiently hard
> to use that I refrained.  All the more when I can't actually compile
> that code.

It's fairly trivial to use, really. See for example pg_SSPI_error in
auth.c. But if it only happens rarely, we shouldn't need it. Let's try it
with just an int for now, and we can perhaps detect the specific cases when
it happens often, and deal with those separately.

I can put together one that uses messages if you want me to (since I can
compile it...) though. I assume you consider your current patch safe enough
not to need help buiklding that part before it hits the buildfarm :-P


//Magnus

In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2007-11-28 16:21:57
Subject: Re: PG 7.3 is five years old today
Previous:From: Joshua D. DrakeDate: 2007-11-28 16:20:04
Subject: Re: [HACKERS] Time to update list of contributors

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