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 p
"Bruce Momjian" wrote
>> William ZHANG wrote:
> > - Original Message -
> > > From: "Dave Page"
> > > To: "Andrew Dunstan" <[EMAIL PROTECTED]>; "William ZHANG"
<[EMAIL PROTECTED]>
> > > Cc:
""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
> > > w
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 tabl
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 posting/readin
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 compi
William ZHANG wrote:
> - Original Message -
> > From: "Dave Page"
> > To: "Andrew Dunstan" <[EMAIL PROTECTED]>; "William ZHANG" <[EMAIL
> > PROTECTED]>
> > Cc:
> > Sent: Thursday, September 01, 2005 3:21 PM
>
> 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
"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
> > 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.
>
> > > 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 t
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 libra
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
> develop
- Original Message -
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
To: "Dave Page"
Cc: "William ZHANG" <[EMAIL PROTECTED]>;
Sent: Wednesday, August 31, 2005 10:24 PM
Subject: Re: [HACKERS] Call for 7.5 feature completion
> Dave Page wrote:
&
- Original Message -
> From: "Dave Page"
> To: "Andrew Dunstan" <[EMAIL PROTECTED]>; "William ZHANG" <[EMAIL PROTECTED]>
> Cc:
> Sent: Thursday, September 01, 2005 3:21 PM
> Subject: RE: [HACKERS] Call for 7.5 feature completion
> -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
William ZHANG wrote:
- Original Message -
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
To: "Dave Page"
Cc: "William ZHANG" <[EMAIL PROTECTED]>;
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 comp
> -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.
* 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
--
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 internation
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 bette
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 row
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
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 o
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?
* 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: explain
[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
"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 engi
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
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 lis
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").
Michae
Tom Lane wrote:
> Bruce Momjian 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 thos
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)
Mu
Bruce Momjian 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 rejected as err
Josh Berkus 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 be wonderful ha
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
pgman@c
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:
>
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 s
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 wouldn
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
> >
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 use
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> Or, slightly different, what are people's most wanted features?
MERGE.
Stephen
signature.asc
Description: Digital signature
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
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 mo
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,
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 error
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 oth
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 po
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 tha
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)
* C
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 possib
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
-
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 p
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 clo
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 quer
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 func
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
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 peo
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 t
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 aggre
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 a
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
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 possi
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 p
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 t
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? Do
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 ..
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 tas
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 <= 200
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 ha
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
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 eas
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 do
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_
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,
> 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 i
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 misera
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
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?
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 peo
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
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 se
> 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, b
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 woul
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 o
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
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 --
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 l
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
> testabili
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 pushi
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 w
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
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
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 areas.
Tatsuo Ishii wrote:
At least in Japan PHP is much more popular than Python. If we have
plpython in core, I see no reason we do not have plPHP in core at
least from the "popularity" point of view.
Well I don't know anywhere that PHP isn't more popular than Python. The
question I think
i
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?
Honestly, I don't know if it would be popular enough on its own. Now the
plPerlNG that Andrew
and us are working, yes but plPHP? It is nifty, it is
Marc G. Fournier wrote:
> On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
>
> > I have some confidence in that I will be able to deliver it maybe the last
> > week of May. I can only hope, however, that it will not be rejected because
> > it's presented too close to feature freeze.
>
> There is
> On Tue, 18 May 2004, Joshua D. Drake wrote:
>
> > Actually plPHP doesn't require the PostgreSQL source tree... you would
> > just have to modify the Make file to point to the right places.
>
> So, why tie it into the PostgreSQL source tree? Won't it be popular
> enough to live on its own, that
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
> I have some confidence in that I will be able to deliver it maybe the last
> week of May. I can only hope, however, that it will not be rejected because
> it's presented too close to feature freeze.
There is no such thing as "too close to featur
1 - 100 of 254 matches
Mail list logo
