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

Re: [HACKERS] xlog.c.patch for cygwin port.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, yutaka tanida <yutaka(at)marin(dot)or(dot)jp>, Alexei Zakharov <A(dot)S(dot)Zakharov(at)inp(dot)nsk(dot)su>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] xlog.c.patch for cygwin port.
Date: 2000-03-08 05:50:15
Message-ID: 200003080550.AAA15242@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> On Tue, 7 Mar 2000, Bruce Momjian wrote:
> 
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > > This looks interesting.  We could remove some of our ifwin cruft.
> > > 
> > > I have been thinking for quite some time that most of the CYGWIN32
> > > ifdefs represent very poor programming.  Instead of zillions of
> > > 
> > > #ifndef __CYGWIN32__
> > > 	fd = open(filename, O_RDONLY, 0666);
> > > #else
> > > 	fd = open(filename, O_RDONLY | O_BINARY, 0666);
> > > #endif
> > > 
> > > we should have in one include file something like
> > 
> > Do we ever assign a function pointer for open() anywhere.  If so, the
> > define will not work without some kind of wrapper, right?
> 
> Okay, I'm lost ... if we "#define OPEN_FLAGS .." and not the open itself,
> why would we need some kind of wrapper?

No, the original person was refining open().  Ithink defining the flags
is much better.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2000-03-08 05:54:37
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Previous:From: The Hermit HackerDate: 2000-03-08 05:49:58
Subject: Re: [HACKERS] DROP TABLE inside a transaction block

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