FWIW, I think a lot of people didn't me too on all the features they
want, so I wouldn't put too much weight on the ranking here...
On Mon, Sep 05, 2005 at 05:43:16PM +0200, Peter Eisentraut wrote:
Am Freitag, 26. August 2005 01:13 schrieb Alvaro Herrera:
Or, slightly different, what are
Oh, I remembered another of my personal feature requests for 8.2 :D
* Fix planning and execution of set operations so that they're not
tragically slow. eg. rewriting into outer joins, etc.
Chris
---(end of broadcast)---
TIP 1: if
Am Freitag, 26. August 2005 01:13 schrieb Alvaro Herrera:
Or, slightly different, what are people's most wanted features?
For entertainment, here is a summary the most requested features:
1. MERGE command
2. Table partitioning
2. Materialized views
2. Updatable views
5. Index-organized
Merlin Moncure [EMAIL PROTECTED] 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.
|
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
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
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
Magnus Hagander [EMAIL PROTECTED] 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
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
William ZHANG wrote:
- Original Message -
From: Dave Page dpage@vale-housing.co.uk
To: Andrew Dunstan [EMAIL PROTECTED]; William ZHANG [EMAIL
PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Thursday, September 01, 2005 3:21 PM
Subject: RE: [HACKERS] Call for 7.5 feature
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
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
- Original Message -
From: Dave Page dpage@vale-housing.co.uk
To: Andrew Dunstan [EMAIL PROTECTED]; William ZHANG [EMAIL PROTECTED]
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
- Original Message -
From: Andrew Dunstan [EMAIL PROTECTED]
To: Dave Page dpage@vale-housing.co.uk
Cc: William ZHANG [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Sent: Wednesday, August 31, 2005 10:24 PM
Subject: Re: [HACKERS] Call for 7.5 feature completion
Dave Page wrote
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.
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
On 8/26/05, Alvaro Herrera [EMAIL PROTECTED] wrote:
Or, slightly different, what are people's most wanted features?
One feature, or rather set of features which was missing from the list and I think
it is important: i18n. :)
I mean, PostgreSQL has a number of good features concerning
* Updatable Views per SQL
* INTERVAL data type per SQL
* BLOB/CLOB data type per SQL
* Faster bulk load
* Remove current transaction is aborted, commands ignored ...
* Compile with MSVC on Win32 platforms. MySQL support it.
* Thread safety libpq, ecpg.
--
Regards,
William ZHANG
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
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
William ZHANG wrote:
- Original Message -
From: Andrew Dunstan [EMAIL PROTECTED]
To: Dave Page dpage@vale-housing.co.uk
Cc: William ZHANG [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Sent: Wednesday, August 31, 2005 10:24 PM
Subject: Re: [HACKERS] Call for 7.5 feature completion
In article [EMAIL PROTECTED],
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
* optional interface which sends a row typeoid along with each row in a
result set
Oh, and 'select rowid, * from table' which returns special rowid
column that just incrementally numbers each row.
Why? It's a
On 29 Aug 2005 09:56:44 +0200, Harald Fuchs wrote:
Christopher Kings-Lynne writes:
Oh, and 'select rowid, * from table' which returns special rowid
column that just incrementally numbers each row.
I think you can pretty much do that already by defining your own
aggregate function. The obvious
On Mon, 29 Aug 2005, Christopher Kings-Lynne wrote:
Oh, and 'select rowid, * from table' which returns special rowid column
that just incrementally numbers each row.
In sql2003 there is a window function called ROW_NUMBER() that can be used
to get numbers like that (one also need to specify
Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Oh, and 'select rowid, * from table' which returns special rowid
column that just incrementally numbers each row.
Why?
Perhaps Christopher meant
select row_number() OVER (...) as rowid
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote:
Or, slightly different, what are people's most wanted features?
My approach to that question has been to try to group together
particular use cases. Currently, I see that PostgreSQL is great for web
applications (OLTP) and getting better
* optional interface which sends a row typeoid along with each row in a result
set
Oh, and 'select rowid, * from table' which returns special rowid column
that just incrementally numbers each row.
Chris
---(end of broadcast)---
TIP 6:
On Aug 27, 2005, at 2:45 AM, Heikki Linnakangas wrote:
* support for Tutorial D as an alternative to SQL. It would be
great for educational purposes.
++
I'd also like to see temporal/interval/period support a la Date/
Darwen/Lorentzos (Temporal Data and the Relational Model).
Michael
On Fri, 26 Aug 2005, Heikki Linnakangas wrote:
* support for Tutorial D as an alternative to SQL. It would be great for
educational purposes.
Hmm... we could call it POSTQUEL :-).
Gavin
---(end of broadcast)---
TIP 4: Have you searched our list
Michael Glaesemann said:
On Aug 27, 2005, at 2:45 AM, Heikki Linnakangas wrote:
* support for Tutorial D as an alternative to SQL. It would be great
for educational purposes.
++
I disagree.
This strikes me as something that belongs in a research project, not in the
core, at least for
Andrew Dunstan [EMAIL PROTECTED] writes:
* support for Tutorial D as an alternative to SQL. It would be great
for educational purposes.
This strikes me as something that belongs in a research project, not in the
core, at least for now.
For better or worse, Postgres is a SQL engine; I can't
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Or, slightly different, what are people's most wanted features?
- Vacuum Space Map - Maintain a map of recently-expired rows
This allows vacuum to target specific pages for possible free
space without requiring a sequential scan.
- Deferrable
On Thu, 25 Aug 2005, Josh Berkus wrote:
SavePoints be able to use within functions. ( I think this involves
making procedures that execute outside of a transaction)
Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages.
You can't use savepoints, you can trap errors
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
On N, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote:
We have gone a long way now, even though it was only a year ago. My
question for everyone on this list is: What are the few remaining big
features that you see missing for PostgreSQL?
Or, slightly different, what are people's most
On Thu, Aug 25, 2005 at 07:13:18PM -0400, Alvaro Herrera wrote:
Bruce, on May 17, 2004, you wrote:
So, yea, I am frustrated. I know these features are hard and
complex, but I want them for PostgreSQL, and I want them as soon
as possible. I guess what really bugs me is that we are so
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
Or, slightly different, what are people's most wanted features?
MERGE.
Stephen
signature.asc
Description: Digital signature
Dennis Bjorklund wrote:
On Thu, 25 Aug 2005, Josh Berkus wrote:
SavePoints be able to use within functions. ( I think this involves
making procedures that execute outside of a transaction)
Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages.
You can't
On Fri, 2005-08-26 at 13:13 -0400, Nicholas Walker wrote:
You can't use savepoints, you can trap errors which is implemented using
savepoints. You still might want to write code like this:
BEGIN
SAVEPOINT foo;
IF SOME_ERROR_CODE = 1234 THEN
ROLLBACK TO SAVEPOINT
On Thu, 25 Aug 2005, Alvaro Herrera wrote:
Or, slightly different, what are people's most wanted features?
Since you asked:
* concurrent, partial vacuum that would for example only scan pages that
happen to be in memory
* index-only scans
* database assertions
* lightwight PITR that
Alvaro Herrera wrote:
Or, slightly different, what are people's most wanted features?
Things I would have found useful in the past year or so include:
Standards stuff:
* Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data)
* The elementary OLAP stuff
Contrib related
Hi all,
Our organizations are doing a lot of real time reporting involving
queries with multiple tables, and large tables. I found that two
features are very nice to have:
- Table Partition
- Materialized view
Thanks,
J
On 8/26/05, Ron Mayer [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
Ron Mayer wrote:
* more sane math with intervals. For example, try:
select '0.01 years'::interval, '0.01 months'::interval;
Added to TODO:
Fix SELECT '0.01 years'::interval, '0.01 months'::interval;
--
Bruce Momjian| http://candle.pha.pa.us
Josh Berkus josh@agliodbs.com writes:
Oh, yeah I forgot:
-- windowing functions (e.g. RANK, RANK OVER, LAST 10)
Include this URL or one like it in any TODO about this:
http://publib.boulder.ibm.com/infocenter/rb63help/topic/com.ibm.redbrick.doc6.3/sqlrg/sqlrg36.htm#sii-06-62323
It would
Bruce Momjian pgman@candle.pha.pa.us writes:
Ron Mayer wrote:
* more sane math with intervals. For example, try:
select '0.01 years'::interval, '0.01 months'::interval;
Added to TODO:
Fix SELECT '0.01 years'::interval, '0.01 months'::interval;
Arguably, both of those things should be
What everybody else said. :) But if it comes to voting...
Anything to improve parallelism is good.
Anything reducing blocking (ie: CLUSTER, VACUUM FULL) is good
Improved handling of sort_mem (I think this will hit bizgres first)
merge :)
STATISTICS ON INDEXES! (specifically multi-field indexes)
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Ron Mayer wrote:
* more sane math with intervals. For example, try:
select '0.01 years'::interval, '0.01 months'::interval;
Added to TODO:
Fix SELECT '0.01 years'::interval, '0.01 months'::interval;
Arguably, both
Bruce, on May 17, 2004, you wrote:
So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is that we are so close to having these few
remaining big features, and because they are
We have gone a long way now, even though it was only a year ago. My
question for everyone on this list is: What are the few remaining big
features that you see missing for PostgreSQL?
Table partitioning is pretty big but I believe we have that already for
8.2 per Greenplum.
Better
On Thu, 25 Aug 2005, Alvaro Herrera wrote:
Bruce, on May 17, 2004, you wrote:
So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is that we are so close to having these
On 8/25/05 4:13 PM, Alvaro Herrera [EMAIL PROTECTED] wrote:
We have gone a long way now, even though it was only a year ago. My
question for everyone on this list is: What are the few remaining big
features that you see missing for PostgreSQL?
Or, slightly different, what are people's most
Alvaro,
We have gone a long way now, even though it was only a year ago. My
question for everyone on this list is: What are the few remaining big
features that you see missing for PostgreSQL?
-- on-disk bitmaps and composite indexes (due out for Bizgres in about a
month)
-- More table
Gavin Sherry wrote:
Or, slightly different, what are people's most wanted features?
SQL:
Grouping sets
Recursive queries
Window functions
Updatable views
Updatable cursors
Materialised views
Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step through?
Cost estimation for
Alvaro,
-- on-disk bitmaps and composite indexes (due out for Bizgres in about a
month)
-- More table partitioning stuff
-- materialized view support
-- streams (per TelegraphCQ)
-- database ASSERTIONS
-- clustering (SlonyII)
-- multi-threaded/process query execution (i.e. one query,
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote:
Bruce, on May 17, 2004, you wrote:
So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is that we are so close to
Rod Taylor wrote:
* Multi-CPU sorts. Take a large single sort like an index creation
and split the work among multiple CPUs.
This really implies threading, doesn't it? And presumably it would have
many possible uses besides this one for doing parallel work, e.g. maybe
the
We have gone a long way now, even though it was only a year ago. My
question for everyone on this list is: What are the few remaining big
features that you see missing for PostgreSQL?
Or, slightly different, what are people's most wanted features?
Oh, and MERGE :D
Chris
On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote:
Rod Taylor wrote:
* Multi-CPU sorts. Take a large single sort like an index creation
and split the work among multiple CPUs.
This really implies threading, doesn't it? And presumably it would have
many possible uses
We have gone a long way now, even though it was only a year ago. My
question for everyone on this list is: What are the few remaining big
features that you see missing for PostgreSQL?
Or, slightly different, what are people's most wanted features?
* Recursive unions (ie. WITH recursive)
*
Rod Taylor wrote:
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote:
Bruce, on May 17, 2004, you wrote:
So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is
Rod Taylor wrote:
On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote:
Rod Taylor wrote:
* Multi-CPU sorts. Take a large single sort like an index creation
and split the work among multiple CPUs.
This really implies threading, doesn't it? And presumably it would have
many
Nicholas,
You are a novice user, aren't you? ;-)
I am just a novice end user, but I would like to see:
SavePoints be able to use within functions. ( I think this involves
making procedures that execute outside of a transaction)
Nope, supported in 8.0 for PL/pgSQL. Not sure about other
David Garamond wrote:
Robert Treat wrote:
Given that the cygwin version is currently labeled as not ready for
production I would say you are right. The truth is that many will never
declare win32 good for production simply because of the OS it runs on,
but we still want to make it as solid as
We could perhaps do something similar to the Apache 1.3 win platform
notes, where they (still) say *something* like :
Apache on windows is not as stable as on unix... but is being actively
improved all the time
This is a bit more positive than it's dangerous!.
As for people not reading the
Robert Treat wrote:
Given that the cygwin version is currently labeled as not ready for
production I would say you are right. The truth is that many will never
declare win32 good for production simply because of the OS it runs on,
but we still want to make it as solid as possible.
People _do_ use
On Thu, 2004-05-20 at 19:59, Gaetano Mendola wrote:
Greg Copeland wrote:
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple
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
Greg Copeland wrote:
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
fact that checkpoints, vacuum runs and pg_dumps bog down their machines
to the state where simple queries take several seconds care that much
for any Win32 port?
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What can be done? Well, money from Fujitsu and other companies
(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit
some of these bigger items, so hopefully that will move us forward
in these complex
On Wed, 19 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
There is no such thing as too close to feature freeze, nor has there
ever been in the past ... other then missing it altogether. Unless there
are some serious flaws in the implementation, submitting it on May 31st
would
Richard Huxton wrote:
What can be done? Well, money from Fujitsu and other companies
(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit
some of these bigger items, so hopefully that will move us forward
in these complex areas. I am not sure what could have been done to
push
Richard Huxton [EMAIL PROTECTED] writes:
I'm one of those that should probably be testing early. As it stands,
I'm subscribed to -hackers and if I downloaded a snapshot from today I
still don't know what it is I'd be testing.
How about a series of mini-releases (say) every 8 weeks - 7 weeks
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
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.
Josh Berkus [EMAIL PROTECTED] 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
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
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
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
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
Peter Eisentraut [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
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.
JDBC seems to
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
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 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
On Wed, May 19, 2004 at 09:20:57AM +0800, Christopher Kings-Lynne wrote:
Seriously though, we all have the roles that we play. I don't think
redirecting specific resources to other
resources will help beyond slowing up the original resources.
And now Neil's on holidays :)
Not yet I hope.
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
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
Amen. plperlNG was always intended as a replacement.
In fact, one of the reasons I'm a bit sad about us rushing to feature
freeze on 1 June is that Joshua and I had hoped to get a greatly beefed
up plperl ready in time for 7.5, but I don't think we can make June 1.
I don't think we will make
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
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
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
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
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
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
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)
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
Am Tuesday 18 May 2004 07:40 schrieb Greg Copeland:
From the FAQ (http://www.drbd.org/316.html):
Q: Can XFS be used with DRBD?
A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed.
Hope we're talking about the same project. ;)
Hmmm, interesting. But I did not find 0.7 on
Marc G. Fournier wrote:
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
Joshua D. Drake wrote:
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that
(as long as the code was good enough) that we could incorporate
plPHP???
One reason against including plPHP in the core would be
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
Peter Eisentraut wrote:
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
Marko Karppinen wrote:
I guess the key thing is that pgFoundry shouldn't be a community
distinct from the core. The same community standards need to apply
on both sides of the fence.
[snip]
Thanks Marko, you just wrote exactly what I was concerned about with
features rather than applications
1 - 100 of 249 matches
Mail list logo