Thread: Call for 7.5 feature completion

Call for 7.5 feature completion

From
mike g
Date:
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






Re: Call for 7.5 feature completion

From
"Magnus Hagander"
Date:
> > 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



Re: Call for 7.5 feature completion

From
Claudio Natoli
Date:
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>


Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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


Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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


Re: Call for 7.5 feature completion

From
Tom Lane
Date:
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


Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:
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


Re: Call for 7.5 feature completion

From
Robert Treat
Date:
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



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Magnus Hagander"
Date:
> 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



Re: Call for 7.5 feature completion

From
Hans-Jürgen Schönig
Date:
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



Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Core vs non-Core (Was: Re: Call for 7.5 feature completion)

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Andrew Dunstan"
Date:
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




Re: Call for 7.5 feature completion

From
"Andrew Dunstan"
Date:
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




Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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



Re: Call for 7.5 feature completion

From
"Merlin Moncure"
Date:
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


Re: Call for 7.5 feature completion

From
"Dave Page"
Date:

> -----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.


Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:

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


Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:

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


Re: Call for 7.5 feature completion

From
"Dave Page"
Date:

> -----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.


Re: Call for 7.5 feature completion

From
"William ZHANG"
Date:
----- 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.

Re: Call for 7.5 feature completion

From
"William ZHANG"
Date:
----- 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.

Re: Call for 7.5 feature completion

From
"Merlin Moncure"
Date:
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




Re: Call for 7.5 feature completion

From
Steve Atkins
Date:
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



Re: Call for 7.5 feature completion

From
"Merlin Moncure"
Date:
> > > 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


Re: Call for 7.5 feature completion

From
"Magnus Hagander"
Date:
> > 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


Re: Call for 7.5 feature completion

From
Tom Lane
Date:
"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


Re: Call for 7.5 feature completion

From
"Zeugswetter Andreas DAZ SD"
Date:
> 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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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/


Re: Call for 7.5 feature completion

From
"William ZHANG"
Date:
""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
>




Re: Call for 7.5 feature completion

From
"William ZHANG"
Date:
"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
>