Обсуждение: Call for 7.5 feature completion
Sorry for not replying to a thread but I have a digest subscription... Thank you hackers for all your hard work!!! I use PostgreSQL everyday and love it. My current job would be impossible if I was forced to use MS Access. I don't mind using postgres under cygwin but would much rather use a native windows port. I am still must use 7.4.1 under cygwin until Redhat releases cygwin 1.5.10. Running under cygwin will probably always force windows users to be behind the latest and greatest postgresql version. As postgresql gets more complex I fear it will fall further behind. I am not a cygwin programmer but making sure changes to the cygwin dll are compatible with windows and all the individual packages it also supports can't be very easy. I will continue to patiently wait for windows version. Even if it means 8.0. If only I was skilled enough to help out..... Mike
> > That is the plan ... unless someone knows a reason why they > can't be > > built independently of the core? > > How about this one: Everything we have moved from the core > to gborg so far has been a miserable failure. The code is no > longer maintained, or maintained by three different competing > groups, the documentation has disappeared, the portability is > no longer taken care of, and only the bravest souls even dare > look at the stuff. I think before you move anything more, > you need to have a strong, convincing community on the > receiving side rather than just kicking things out and hoping > someone will pick it up. Just because it can be built > separately doesn't mean everything needs to be. Another thing is how the end user gets to the files. As an end user, you'd generally not care which CVS server the code is on. What you *do* care about is that it's included in the main RPM/DEB or whatever *and* the main source tarball (if I download "complete server", I certainly want a complete server. Including for example PLs, which is one of postgresqls strengths..). Same goes for the docs, of course. If it's in main CVS you get the benefit of having it included in the normal "release management". Sure, it adds a burden on the release management work, but that job has to be done somewhere. And id you just pull in "whatever version happens to be latest" and put this in the release version, you are probably in for some nasty surprises. //Magnus
Greg Copeland writes: > My primary fear about delivering Win32 with all of these other great > features is that, IMO, there is a higher level of risk associated with > these advanced features. At the same time, this will be the > first trial for many Win32 users. Should there be some problems, in general, > or worse, specific to Win32 users as it relates to these new features, it > could cost some serious Win32/PostgreSQL community points. A troubled > release which is experienced by Win32 users is going to be a > battle cry for MySQL. Just thought I'd jump in here with my $0.02. It was always my expectation that the first Win32 release, regardless of the features which accompanied it, would be clearly advertised as not for production (some here might suggest that simply mentioning Win32 and "not for production" in the same sentence is repeating myself, but I'm not going to be quite so cynical). It won't stop people going ahead and doing it regardless, but it buys us some press insurance. I'm confident that the Win32 port will be solid, and will go a long way in boosting PostgreSQLs popularity. That said, I simply don't think it isn't reasonable to expect that it'll go out the door with all quirks nailed the very first time, and we ought to be honest and up-front about these expectations. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
People, > >So, why tie it into the PostgreSQL source tree? Won't it be popular > >enough to live on its own, that it has to be distributed as part of the > >core? Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, as part of the core distribution -- when we are pushing the interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying to lighten up the core, or we're not. But right now there seems to be no logic in operation. I do think, though, that we need some system to build RPMs for all the pgFoundry stuff ... -- Josh Berkus Aglio Database Solutions San Francisco
Tom, > The main downside of testing a snapshot, as I see it, is that the > snapshot is virtually certain not to be initdb-compatible with either > the previous release or the upcoming one. Mini-releases would have > that problem too, and so I don't really see what they add in terms of > testability. The main purpose of mini-releases would be to make testing more accessable to newbies who find anon-CVS intimidating. However, there's no point in worrying about lowering the barriers of entry unless we have a program and a coordinator to make some kind of real use of these newbies' feedback. Anybody wanna volunteer to be 7.5 testing coordinator? -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> The main purpose of mini-releases would be to make testing more
> accessable to newbies who find anon-CVS intimidating.
Who said anything about anon-CVS? There are the nightly snapshots
for those who want a tarball.
regards, tom lane
Josh Berkus wrote: >People, > > > >>>So, why tie it into the PostgreSQL source tree? Won't it be popular >>>enough to live on its own, that it has to be distributed as part of the >>>core? >>> >>> > >Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL, >as part of the core distribution -- when we are pushing the interfaces, such >as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying >to lighten up the core, or we're not. But right now there seems to be no >logic in operation. > >I do think, though, that we need some system to build RPMs for all the >pgFoundry stuff ... > > > Server-side PLs might have quite different requirements from Client Interfaces. I don't think you can simply extrapolate in this way. Personally, I hate the idea of having to write stuff like this example Joe Conway gave the other day from PL/R: #if (CATALOG_VERSION_NO <= 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO <= 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif and all the consequent mess. Yuck. Frankly, although I am a relative newcomer around here, I am not convinced that "lightening the core" has been a great success, or can be made to be so. Certainly Peter's comments on the history to date suggest that a re-evaluation might be in order. cheers andrew
On Wed, 2004-05-19 at 12:55, Josh Berkus wrote:
> Tom,
>
> > The main downside of testing a snapshot, as I see it, is that the
> > snapshot is virtually certain not to be initdb-compatible with either
> > the previous release or the upcoming one. Mini-releases would have
> > that problem too, and so I don't really see what they add in terms of
> > testability.
>
> The main purpose of mini-releases would be to make testing more accessable to
> newbies who find anon-CVS intimidating.
>
FWIW we already do nightly tarballs that people can use to build from if
they want...
What might be handy is an alpha build of the win32 version once the
folks developing it feel it's stable enough to merit such a thing...
Course as Bruce mentioned in a post somewhere 'round here, testing is
not the real deficiency here, people who can help code is.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Andrew Dunstan wrote: > Frankly, although I am a relative newcomer around here, I am not > convinced that "lightening the core" has been a great success, or can be > made to be so. Certainly Peter's comments on the history to date suggest > that a re-evaluation might be in order. Moving stuff out makes their release schedules and community involvement independent, but from a code activity and ease-of-use perspective, it has been a general failure, with only a few successes. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Robert Treat wrote: > On Wed, 2004-05-19 at 12:55, Josh Berkus wrote: > > Tom, > > > > > The main downside of testing a snapshot, as I see it, is that the > > > snapshot is virtually certain not to be initdb-compatible with either > > > the previous release or the upcoming one. Mini-releases would have > > > that problem too, and so I don't really see what they add in terms of > > > testability. > > > > The main purpose of mini-releases would be to make testing more accessable to > > newbies who find anon-CVS intimidating. > > > > FWIW we already do nightly tarballs that people can use to build from if > they want... > > What might be handy is an alpha build of the win32 version once the > folks developing it feel it's stable enough to merit such a thing... The Win32 project page already has nightly Win32 builds courtesy of Magnus. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> What might be handy is an alpha build of the win32 version > once the folks developing it feel it's stable enough to merit > such a thing... http://www.hagander.net/pgsql/win32snap/ Merlin has set a job up that compiles it daily. It may be broken right this minute because of the exec stuff, but it updates there normally. The link is also on the win32 status page. //Magnus
Josh Berkus wrote:
> People,
>
>
>>>So, why tie it into the PostgreSQL source tree? Won't it be popular
>>>enough to live on its own, that it has to be distributed as part of the
>>>core?
>
>
> Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
> as part of the core distribution -- when we are pushing the interfaces, such
> as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying
> to lighten up the core, or we're not. But right now there seems to be no
> logic in operation.
>
> I do think, though, that we need some system to build RPMs for all the
> pgFoundry stuff ...
>
As far as this discussion is concerned I personally think that there is
just one way to satisfy everybody.
I we had a "PostgreSQL most wanted" distribution including PL/* as well
as some other modules we could save people compiling PostgreSQL from
source a lot of work.
The core itself would be cleaner (which is the target of moving things
out) and everybody would be happy?
If people think this is a good idea I could compile and maintain this
(source) distribution ...
Best regards,
Hans
--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
Tom, > > The main purpose of mini-releases would be to make testing more > > accessable to newbies who find anon-CVS intimidating. > > Who said anything about anon-CVS? There are the nightly snapshots > for those who want a tarball. Really? Where are they? I'd like to be able to refer people. -- -Josh BerkusAglio Database SolutionsSan Francisco
Josh Berkus wrote: > Tom, > > > > The main purpose of mini-releases would be to make testing more > > > accessable to newbies who find anon-CVS intimidating. > > > > Who said anything about anon-CVS? There are the nightly snapshots > > for those who want a tarball. > > Really? Where are they? I'd like to be able to refer people. On the ftp server under /dev. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, 19 May 2004, Josh Berkus wrote: > People, > > > >So, why tie it into the PostgreSQL source tree? Won't it be popular > > >enough to live on its own, that it has to be distributed as part of the > > >core? > > Personally, I find it rather inconsistent to have any PL, other than > PL/pgSQL, as part of the core distribution -- when we are pushing the > interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. Actually, JDBC, libpqxx, ODBC, plPHP, plPerlNG are all really easy to push over to pgFoundry ... they have very active, and visible, developers responsible for them ... is anyone out there directing work on pl/pgsql or pl/TCL? If so, they are easy to move also ... > Either we're trying to lighten up the core, or we're not. But right now > there seems to be no logic in operation. Its easier to *not add* something to core (ie. plPHP/plPerlNG) then it is to remove something (see JDBC) ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 19 May 2004, Andrew Dunstan wrote: > Personally, I hate the idea of having to write stuff like this example > Joe Conway gave the other day from PL/R: > > #if (CATALOG_VERSION_NO <= 200211021) > #define PG_VERSION_73_COMPAT > #elif (CATALOG_VERSION_NO <= 200310211) > #define PG_VERSION_74_COMPAT > #else > #define PG_VERSION_75_COMPAT > #endif Why not have seperate branches in CVS for each version? Branch on similar dates to the core distribution itself? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 19 May 2004, [ISO-8859-1] Hans-J�rgen Sch�nig wrote: > If people think this is a good idea I could compile and maintain this > (source) distribution ... I'd love to see something like this ... One question I have is what would it take to extend teh build system in core so that it was easier to do this? For instance, for those wishing to do something like this, what would it take to have it so that you could 'cvs checkout': pgsql (the core) pgsql/src/interfaces/jdbc (from pgfoundry) pgsql/src/interfaces/odbc (from pgfoundry) I know that pulling in the various source codes isn't a difficult script to write, but how about adding in the building of the included modules? Maybe have the optional modules in a pgsql/src/modules directory? I know its doable ... apache does it ... ... and I've seen other software/projects where configure in the root calls configure in the modules directory itself, so that's doable ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 19 May 2004, Josh Berkus wrote: > Tom, > > > The main downside of testing a snapshot, as I see it, is that the > > snapshot is virtually certain not to be initdb-compatible with either > > the previous release or the upcoming one. Mini-releases would have > > that problem too, and so I don't really see what they add in terms of > > testability. > > The main purpose of mini-releases would be to make testing more accessable to > newbies who find anon-CVS intimidating. what is wrong with the nightly snapshots that are created? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 19 May 2004, Bruce Momjian wrote: > The Win32 project page already has nightly Win32 builds courtesy of > Magnus. Do you want to setup an scp into the main ftp site so that the mirrors catch them as well? Might make it easier for ppl to get ahold of it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier said: > On Wed, 19 May 2004, Josh Berkus wrote: > >> People, >> >> > >So, why tie it into the PostgreSQL source tree? Won't it be >> > >popular enough to live on its own, that it has to be distributed as >> > >part of the core? >> >> Personally, I find it rather inconsistent to have any PL, other than >> PL/pgSQL, as part of the core distribution -- when we are pushing the >> interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry. > > Actually, JDBC, libpqxx, ODBC, plPHP, plPerlNG are all really easy to > push over to pgFoundry ... they have very active, and visible, > developers responsible for them ... is anyone out there directing work > on pl/pgsql or pl/TCL? If so, they are easy to move also ... > >> Either we're trying to lighten up the core, or we're not. But right >> now there seems to be no logic in operation. > > Its easier to *not add* something to core (ie. plPHP/plPerlNG) then it > is to remove something (see JDBC) ... > plperlng is not "something not in the core". It is a project to improve something that *is* in the core. That has always been my intention, and it is clear from his comments that it has always been Joshua Drake's too. cheers andrew
Marc G. Fournier said: > On Wed, 19 May 2004, Andrew Dunstan wrote: > >> Personally, I hate the idea of having to write stuff like this example >> Joe Conway gave the other day from PL/R: >> >> #if (CATALOG_VERSION_NO <= 200211021) >> #define PG_VERSION_73_COMPAT >> #elif (CATALOG_VERSION_NO <= 200310211) >> #define PG_VERSION_74_COMPAT >> #else >> #define PG_VERSION_75_COMPAT >> #endif > > Why not have seperate branches in CVS for each version? Branch on > similar dates to the core distribution itself? > And thus demolish your argument that it is in the interests of projects to have independent release dates. And make the task more complex. All this will do is make life harder. We should be about making it easier. cheers andrew
On Wed, 19 May 2004, Andrew Dunstan wrote: > > Why not have seperate branches in CVS for each version? Branch on > > similar dates to the core distribution itself? > > > > And thus demolish your argument that it is in the interests of projects to > have independent release dates. And make the task more complex. How do you figure that? If you do a 7.4 branch of a project, around the same time as 7.4 of PostgreSQL, you have code that is specific to that release that you can apply patches/improvements to. By being a seperate project, you don't hvae to wait for 7.4.1 to be released in order to release a new version of the project ... I'm not even say call it a 7.4 branch ... just associate it with it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc, > what is wrong with the nightly snapshots that are created? Nothing. I was just clueless that this was set up. So, the 2nd step is to find a likely victi^H^H^H^Holunteer to coordinate platform/feature testing among our large population of mailing list users. Easier said than done ... -- -Josh BerkusAglio Database SolutionsSan Francisco
Alvaro wrote: > Or, slightly different, what are people's most wanted features? 1. Proper row constructor, such that select (1,2,1) > (2,1,1); returns the right answer, and select * from t where (t1,t2,t3) > (c1, c2, c3) order by t1,t2,t3 limit 1 returns the right answer and uses a index on t1,t2,t3 if it exists. this is on the TODO. 2. In the planner, a parameterized limit for prepared statements to assume a small value (like 1). 3. Ability to create arrays of composite types (and nest them). > Has PostgreSQL started slowing down in getting new features, and > concentrating mostly on performance issues? nope! Merlin
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of William ZHANG > Sent: 31 August 2005 10:51 > To: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Call for 7.5 feature completion > > * Faster bulk load Done, iirc. > * Compile with MSVC on Win32 platforms. MySQL support it. So what? It would take a major amount of work, with no useful benefits. > * Thread safety libpq, ecpg. Done. Regards, Dave.
Dave Page wrote: > > >>* Compile with MSVC on Win32 platforms. MySQL support it. >> >> > >So what? It would take a major amount of work, with no useful benefits. > > > ... and you can compile all the client and library stuff with MSVC - just not the server nor extensions. But the audience for compiling those is far smaller. cheers andrew
William ZHANG wrote: >----- Original Message ----- >From: "Andrew Dunstan" <andrew@dunslane.net> >To: "Dave Page" <dpage@vale-housing.co.uk> >Cc: "William ZHANG" <uniware@zedware.org>; <pgsql-hackers@postgresql.org> >Sent: Wednesday, August 31, 2005 10:24 PM >Subject: Re: [HACKERS] Call for 7.5 feature completion > > > > >>Dave Page wrote: >> >> >>>>* Compile with MSVC on Win32 platforms. MySQL support it. >>>> >>>> >>>> >>>So what? It would take a major amount of work, with no useful benefits. >>> >>> >>... and you can compile all the client and library stuff with MSVC - >>just not the server nor extensions. But the audience for compiling those >>is far smaller. >> >> > >I think the most popular method to build a project on Win32 is using >MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help >developers increase their productivity. Actually I have tried to make >the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. >Should I polish it and send it as a patch? > >Having been a Win32 developer for several years, I think it is more >convenient to use MSVC's IDE than CL.exe with NMAKE.exe. >Although I do not like Microsoft very much, and like to use MinGW >or Cygwin to do some small tests, MSVC is more suitable for >native Win32 development. If pgsql want to be the first class citizen >on Windows, and want to compete with MySQL, I think supporting >MSVC is important. I beleive there will be many contributions from >the Win32 world. > > > You are missing the point. We are not prepared to support two completely different build systems. Our build system is very very heavily dependent on gmake. So if you want to change the build system you have to come up with something that works everywhere. COming up with a project file or an nmake file for Windows is not hard. Keeping them in step with everything else is very hard. We currently have nmake files for the client libraries, but project files might be good to have too, and I don't think we have those. Why not start a pgfoundry project to publish some MSVC project files, at least for the client libs? cheers andrew
> -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: 01 September 2005 03:31 > To: William ZHANG > Cc: Dave Page; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Call for 7.5 feature completion > > > We currently have nmake files for the client libraries, And even those are a royal pain to maintain, never mind an entire set. Besides, I'm sure what William really wants is not nmake files, but VC++ Project files - but then which version do we keep? It's not like we could say that everyone should be using VS2005, so all commits would have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to complain. I agree with Andrew though - maintaining VC++ project files or nmake files is just not practical - especially given that most of our developers are not Windows users. Regards, Dave.
----- Original Message ----- > From: "Dave Page" <dpage@vale-housing.co.uk> > To: "Andrew Dunstan" <andrew@dunslane.net>; "William ZHANG" <uniware@zedware.org> > Cc: <pgsql-hackers@postgresql.org> > Sent: Thursday, September 01, 2005 3:21 PM > Subject: RE: [HACKERS] Call for 7.5 feature completion > > And even those are a royal pain to maintain, never mind an entire set. > Besides, I'm sure what William really wants is not nmake files, but VC++ > Project files - but then which version do we keep? It's not like we > could say that everyone should be using VS2005, so all commits would > have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to > complain. You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the project files is created, the maintance work is simply add/remove some new/deleted source files (*.c only) from the dsps. And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's development. And latter versions of VC++ can automatically convert 6.0's project files. There are also a "VC++7 to VC++6 project converter" on www.codeproject.com. > I agree with Andrew though - maintaining VC++ project files or nmake > files is just not practical - especially given that most of our > developers are not Windows users. I am expecting more and more Windows users to join us. According to Andrew's advice, I will try to start a project on pgfoundry to provide the VC++ project files. > Regards, Dave.
----- Original Message ----- From: "Andrew Dunstan" <andrew@dunslane.net> To: "Dave Page" <dpage@vale-housing.co.uk> Cc: "William ZHANG" <uniware@zedware.org>; <pgsql-hackers@postgresql.org> Sent: Wednesday, August 31, 2005 10:24 PM Subject: Re: [HACKERS] Call for 7.5 feature completion > Dave Page wrote: > > > >>* Compile with MSVC on Win32 platforms. MySQL support it. > >> > >So what? It would take a major amount of work, with no useful benefits. > > ... and you can compile all the client and library stuff with MSVC - > just not the server nor extensions. But the audience for compiling those > is far smaller. I think the most popular method to build a project on Win32 is using MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help developers increase their productivity. Actually I have tried to make the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. Should I polish it and send it as a patch? Having been a Win32 developer for several years, I think it is more convenient to use MSVC's IDE than CL.exe with NMAKE.exe. Although I do not like Microsoft very much, and like to use MinGW or Cygwin to do some small tests, MSVC is more suitable for native Win32 development. If pgsql want to be the first class citizen on Windows, and want to compete with MySQL, I think supporting MSVC is important. I beleive there will be many contributions from the Win32 world.
William wrote: > You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the > project files is created, the maintance work is simply add/remove some > new/deleted source files (*.c only) from the dsps. > > And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's > development. And latter versions of VC++ can automatically convert 6.0's > project files. There are also a "VC++7 to VC++6 project converter" on > www.codeproject.com. You might be surprised to know that this has been already done. Back in the 7.2 cycle there was a win32 build floating around that compiled and built inside of visual studio 6. I think Jan Wieck was one of the people involved in the effort. That would be a good place to start looking. Merlin
On Thu, Sep 01, 2005 at 09:17:38AM +0800, William ZHANG wrote: > > Dave Page wrote: > > > > > >>* Compile with MSVC on Win32 platforms. MySQL support it. > > >> > > >So what? It would take a major amount of work, with no useful benefits. > > > > ... and you can compile all the client and library stuff with MSVC - > > just not the server nor extensions. But the audience for compiling those > > is far smaller. > > I think the most popular method to build a project on Win32 is using > MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help > developers increase their productivity. Actually I have tried to make > the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. > Should I polish it and send it as a patch? > > Having been a Win32 developer for several years, I think it is more > convenient to use MSVC's IDE than CL.exe with NMAKE.exe. > Although I do not like Microsoft very much, and like to use MinGW > or Cygwin to do some small tests, MSVC is more suitable for > native Win32 development. If pgsql want to be the first class citizen > on Windows, and want to compete with MySQL, I think supporting > MSVC is important. I beleive there will be many contributions from > the Win32 world. I think supporting MSVC is important, certainly (though I think that supporting the Intel compiler is even better, as the only compelling reason, IMO, to switch for the server end is generated code quality). But that's very different from supporting visual studio. I've been doing cross-platform development on a big codebase for years, and the idea of trying to use the proprietary build environments on each platform, and expecting to keep them sufficiently in-sync that the end result is actually comparable on each platform is laughable. And that's on a much smaller, simpler codebase than PG with a much smaller, more integrated development team. I use gmake or cons everywhere. On Windows I run them under cygwin and have them call the MSVC commandline compiler. It all works fine. And it doesn't stop me from using Visual Studio to edit the code, run the debugger or anything like that. On OS X I can use XCode. On Solaris I use the Forte environment. On Linux I use emacs and gcc. And that's all on the same codebase with the same makefile checked out from the same CVS repository. Cheers, Steve
> > > And I think VC++ 6.0 is ok, it is power enough and not so big for > pgsql's > > development. And latter versions of VC++ can automatically convert > 6.0's > > project files. There are also a "VC++7 to VC++6 project converter" on > > www.codeproject.com. > > | You might be surprised to know that this has been already done. Back in > | the 7.2 cycle there was a win32 build floating around that compiled and > | built inside of visual studio 6. I think Jan Wieck was one of the > | people involved in the effort. > > | That would be a good place to start looking. > > | Merlin > > I know sth. about Jan Wieck's work, but cannot find the VC++ projects. > Now I have started a PgFoundry project "vcproject". > > Regards, > William ZHANG The peerdirect port is still available on Bruce's ftp site here: ftp://momjian.postgresql.org/pub/postgresql/win32/PeerDirect/ as a patch vs. the 7.2 postgresql. fwiw, I think your project is in a race against time vs. the upcoming improved win32 posix support. Details are skimpy but the rumors are ms is going to allow running just about any unix app without emulation. Currently the major advantage I see of providing alternative to mingw is providing 64 bit version of postgresql to windows since mingw does not appear to be going 64 bit anytime soon. The win32 build environment issue was discussed quite heatedly when the porting effort started heating up. At the time I advocated for a vc6 build environment but have since then realized that probably would have been a mistake. Merlin
> > I think the most popular method to build a project on Win32 > is using > > MSVC or Intel C. Intel C can be integrated with MSVC's IDE to help > > developers increase their productivity. Actually I have > tried to make > > the backend of pgsql-8.0.3 build with MSVC 6.0, and it works well. > > Should I polish it and send it as a patch? > > > > Having been a Win32 developer for several years, I think it is more > > convenient to use MSVC's IDE than CL.exe with NMAKE.exe. > > Although I do not like Microsoft very much, and like to use > MinGW or > > Cygwin to do some small tests, MSVC is more suitable for > native Win32 > > development. If pgsql want to be the first class citizen on > Windows, > > and want to compete with MySQL, I think supporting MSVC is > important. > > I beleive there will be many contributions from the Win32 world. > > I think supporting MSVC is important, certainly (though I > think that supporting the Intel compiler is even better, as > the only compelling reason, IMO, to switch for the server end > is generated code quality). But that's very different from > supporting visual studio. > > I've been doing cross-platform development on a big codebase > for years, and the idea of trying to use the proprietary > build environments on each platform, and expecting to keep > them sufficiently in-sync that the end result is actually > comparable on each platform is laughable. And that's on a > much smaller, simpler codebase than PG with a much smaller, > more integrated development team. > > I use gmake or cons everywhere. On Windows I run them under > cygwin and have them call the MSVC commandline compiler. It > all works fine. And it doesn't stop me from using Visual > Studio to edit the code, run the debugger or anything like > that. On OS X I can use XCode. On Solaris I use the Forte > environment. On Linux I use emacs and gcc. And that's all on > the same codebase with the same makefile checked out from the > same CVS repository. I think the main problem with switching to visual studio project files is maintainabilty. (It's not easy to get all the custom actions used to build some parts running in VS, but i'm su8re you can do it). The core development is done on Unix, and if you can't use the same Makefiles it's only a matter of time (and I bet very short time) before the VS files would be broken compared to the "main ones" etc. Win32 is a much more "first class citizen" now that it builds with gmake than it would be then. Building with the VC compiler using GNU makefiles is a whole different story - if that can be made to work reasonably easily it would be a worthwhile goal (in my experience, for example, the VSEE compiler optimises things a whole lot better than gcc on win32). I just don't see the payoff in getting rid of make. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
> Building with the VC compiler using GNU makefiles is a whole different
> story - if that can be made to work reasonably easily it would be a
> worthwhile goal (in my experience, for example, the VSEE compiler
> optimises things a whole lot better than gcc on win32). I just don't see
> the payoff in getting rid of make.
+1 here. It's already enough of a pain in the neck taking care of the
Windows-specific build support for libpq and psql; we're not going to
take on maintaining a complete parallel build infrastructure for a
proprietary platform. (In fact, there's been serious discussion of
dropping the Windows-specific build scripts that are there now, as
it's not clear why they are still needed when you can build the stuff
in mingw and then use it elsewhere.) But we already deal with lots of
different compilers, so one more shouldn't be a problem --- as long as
you can drive it with gmake.
regards, tom lane
> I think the main problem with switching to visual studio > project files is maintainabilty. (It's not easy to get all I think the target should be a way to auto create those files with gmake (maybe with mingw for configure). The format of VS6 project and workspace files is pretty simple. It should be possible to derive them from the makefiles and simple templates. Andreas
William ZHANG wrote: > ----- Original Message ----- > > From: "Dave Page" <dpage@vale-housing.co.uk> > > To: "Andrew Dunstan" <andrew@dunslane.net>; "William ZHANG" <uniware@zedware.org> > > Cc: <pgsql-hackers@postgresql.org> > > Sent: Thursday, September 01, 2005 3:21 PM > > Subject: RE: [HACKERS] Call for 7.5 feature completion > > > > > And even those are a royal pain to maintain, never mind an entire set. > > > Besides, I'm sure what William really wants is not nmake files, but VC++ > > Project files - but then which version do we keep? It's not like we > > could say that everyone should be using VS2005, so all commits would > > have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to > > complain. > > You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the > project files is created, the maintance work is simply add/remove some > new/deleted source files (*.c only) from the dsps. > > And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's > development. And latter versions of VC++ can automatically convert 6.0's > project files. There are also a "VC++7 to VC++6 project converter" on > www.codeproject.com. Also, how do you build the backend with VC without the MinGW compatibility routines and include files? I know everyone is focused on the build environment and shell script support, but there is also library code translation support in MinGW too that we use. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Magnus Hagander wrote: > Building with the VC compiler using GNU makefiles is a whole > different story - if that can be made to work reasonably easily it > would be a worthwhile goal The main problem is that the VC compiler uses completely different command-line options than a typical Unix compiler. I recall that there is a wrapper script out there, which would surely be a good starting point for someone investigating this. -- Peter Eisentraut http://developer.postgresql.org/~petere/
""Merlin Moncure"" <merlin.moncure@rcsonline.com> wrote > > > > And I think VC++ 6.0 is ok, it is power enough and not so big for > > pgsql's > > > development. And latter versions of VC++ can automatically convert > > 6.0's > > > project files. There are also a "VC++7 to VC++6 project converter" > on > > > www.codeproject.com. > > > > | You might be surprised to know that this has been already done. > Back in > > | the 7.2 cycle there was a win32 build floating around that compiled > and > > | built inside of visual studio 6. I think Jan Wieck was one of the > > | people involved in the effort. > > > > | That would be a good place to start looking. > > > > | Merlin > > > > I know sth. about Jan Wieck's work, but cannot find the VC++ > projects. > > Now I have started a PgFoundry project "vcproject". > > > > Regards, > > William ZHANG > > The peerdirect port is still available on Bruce's ftp site here: > ftp://momjian.postgresql.org/pub/postgresql/win32/PeerDirect/ > > as a patch vs. the 7.2 postgresql. > > > fwiw, I think your project is in a race against time vs. the upcoming > improved win32 posix support. Details are skimpy but the rumors are ms > is going to allow running just about any unix app without emulation. I remember that Microsoft stopped supporting POSIX subsystem in Win32. Can you give me more information? > Currently the major advantage I see of providing alternative to mingw is > providing 64 bit version of postgresql to windows since mingw does not > appear to be going 64 bit anytime soon. Not thinking about that yet. > The win32 build environment issue was discussed quite heatedly when the > porting effort started heating up. At the time I advocated for a vc6 > build environment but have since then realized that probably would have > been a mistake. > > Merlin > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
"Bruce Momjian" <pgman@candle.pha.pa.us> wrote >> William ZHANG wrote: > > ----- Original Message ----- > > > From: "Dave Page" <dpage@vale-housing.co.uk> > > > To: "Andrew Dunstan" <andrew@dunslane.net>; "William ZHANG" <uniware@zedware.org> > > > Cc: <pgsql-hackers@postgresql.org> > > > Sent: Thursday, September 01, 2005 3:21 PM > > > Subject: RE: [HACKERS] Call for 7.5 feature completion > > > > > > > > And even those are a royal pain to maintain, never mind an entire set. > > > > > Besides, I'm sure what William really wants is not nmake files, but VC++ > > > Project files - but then which version do we keep? It's not like we > > > could say that everyone should be using VS2005, so all commits would > > > have to be VC++ 6.0 or earlier compatible, otherwise someone is bound to > > > complain. > > > > You are right. What I want is VC++ projects(*.dsp, *.dsw). Once the > > project files is created, the maintance work is simply add/remove some > > new/deleted source files (*.c only) from the dsps. > > > > And I think VC++ 6.0 is ok, it is power enough and not so big for pgsql's > > development. And latter versions of VC++ can automatically convert 6.0's > > project files. There are also a "VC++7 to VC++6 project converter" on > > www.codeproject.com. > > Also, how do you build the backend with VC without the MinGW > compatibility routines and include files? I know everyone is focused on > the build environment and shell script support, but there is also > library code translation support in MinGW too that we use. At first, I thought about telling Makfiles to use VC++'s command line CL.exe, LINK.exe. But it is too difficult. Now I want to try in another way. 1. Configure, make, make install pgsql in MinGW first. Bison/flex and the shell scripts will generate some needed files. 2. Build with VC++. We can use its IDE or command line MSDEV.exe. We can now elimate most of the difficulty, and make the VC++ projects an addon. > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend >