On Mon, 17 May 2004, Alvaro Herrera Munoz wrote:
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote:
Can we try to do the 2PC patch now instead of waiting for subtransactions ?
The last post from Heikki I read said that he discovered some serious
problems with his
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
a release, etc ...
I'd almost say that time would be better spent on coming up with an
effective upgrade method so that upgrading to new releases is easier ...
Please note that I'm not against the backporting, but do understand the
arguments against it in terms of time and manpower ...
I
Peter Eisentraut wrote:
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
On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
On Mon, 17 May 2004, Mike Mascari wrote:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any given development effort. If I
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 you think it is a good sign for those who have
Yes. I am one such
Marc G. Fournier wrote:
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any
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 you think
Marc G. Fournier wrote:
On Tue, 18 May 2004, Robert Treat wrote:
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend
Joshua D. Drake wrote:
Except you miss one key point here ... if Bruce/Tom/Jan have that sort of
time, why aren't they doing it now?
Well I think you might of missed his point. His point was if he could
pick their priorities. I would kind
of agree with Robert except that there are
Joshua D. Drake wrote:
One reason against including plPHP in the core would be that it
would create a circular build dependency between the packages
postgresql and php. I think we should rather avoid that.
It is no different that the dependency between plPerl and Perl,
plPython and Python
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.
Yes, and the best way to achieve that would be to not have anything to
pgfoundry and keep everything in the
This is very much different, because the PHP distribution contains the
PostgreSQL driver, whereas the other languages do not. So you would
have
PHP build depends on PostgreSQL
Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL
support to be built into PHP.
Sincerely,
Joshua
That is irrelevant. A normal binary package of PHP does build the
PostgreSQL support (which is surely in our interest), so the build
dependency holds.
Then I am afraid I don't understand the actual problem. plPHP does not
create a circular dependency because it doesn't require PHP to have
Joshua D. Drake wrote:
This is very much different, because the PHP distribution contains
the PostgreSQL driver, whereas the other languages do not. So you
would have
PHP build depends on PostgreSQL
Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL
support to be built
Joshua D. Drake wrote:
Also PHP does not compile the PostgreSQL support by default.
But most binary packages do, and they are the ones I'm talking about.
And surely you do not advocate that, in order to build PL/PHP, the
packagers instead disable the client side support in PHP?
Joshua D. Drake wrote:
Of course not, but I still don't see your point. plPHP doesn't need
PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
plPHP...
PHP doesn't even need to be installed for plPHP to work... You just
need the source tree for building.
I don't talk about
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Of course not, but I still don't see your point. plPHP doesn't need
PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using
plPHP...
PHP doesn't even need to be installed for plPHP to work... You just
need the source tree for building.
-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. I am not sure what
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 :)
Perhaps we need more committers. The deluge of patches is starting to
strain the major
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
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote:
But most binary packages do, and they are the ones I'm talking about.
And surely you do not advocate that, in order to build PL/PHP, the
packagers instead disable the client side support in PHP?
Of course not, but I still don't see your
So you then have to build PHP twice, in an RPM build environment. You mean I
can't just have the headers installed to build plPHP? So, follow the
No you need to make sure that PHP is available as a shared lib.
1.) Build PostgreSQL
2.) Build PHP (with PostgreSQL client support)
3.) Build plPHP
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote:
So you then have to build PHP twice, in an RPM build environment. You
mean I can't just have the headers installed to build plPHP? So, follow
the
No you need to make sure that PHP is available as a shared lib.
Which requires you to
On Tue, 18 May 2004, Heikki Linnakangas wrote:
I'd like to get the patch committed as soon as the 7.6 release cycle
begins, with whatever limitations it has at that time.
The nice thing of this is that then you have a development cycle for
others to help ... your patch lays down the this 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 it has to be
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 feature
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 it has
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 no such
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
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
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want more than a vacuum
patch and
Hans-Jürgen Schönig wrote:
All the clients that I deal with on a daily basis generally care about is
performance ... that is generally what they upgrade for ... so, my
'educated guess' based on real world users is that Win32, PITR and nested
transactions are not important ... tablespaces,
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any
Jan Wieck wrote:
Christopher Kings-Lynne wrote:
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any of the other stuff, like PITR/tablespaces) would be icing on the cake
...
I think we're
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
I thought the outcome of that discussion was June 15 ?
Can we try to do the 2PC patch now instead of waiting for subtransactions ?
Andreas
---(end of
Robert Treat wrote:
On Monday 17 May 2004 08:21, Bruce Momjian wrote:
Hans-J?rgen Sch?nig wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
He is waiting for nested transactions to be committed so he can merge
his work
On Monday 17 May 2004 08:21, Bruce Momjian wrote:
Hans-Jürgen Schönig wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
He is waiting for nested transactions to be committed so he can merge
his work in.
I was thinking about
Jan Wieck wrote:
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
Do you really need
Hans-Jürgen Schönig wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want
Jan Wieck wrote:
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as a
byproduct
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as a
byproduct of a connection pool isn't
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have mentioned
Mario Weilguni wrote:
Interesting. We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have
sychronous replication and PITR?. Performance is not a problem
here. People are more interested in stability and enterprise
features such as those I have
On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote:
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
I think I have to reiterate: PITR won't make 1 June. (I will be away
travelling soon). This has been said a number of times.
This is
Hans-Jürgen Schönig wrote:
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
I didn't find it on pgFoundry, others place to look at it ?
Regards
Gaetano Mendola
---(end of
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster replication as
Simon Riggs wrote:
On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote:
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
Just to throw in my .02, plPerlNG won't be ready for testing until mid,
later June either. Then there is also plPHP
On Mon, 17 May 2004, Joshua D. Drake wrote:
Personally, Win32, subtransactions and PITR are what we are after.
Second would be inclusion of plPHP and plPerlNG which are arguably the
most widely used languages to connect to PostgreSQL.
plPHP and plPerlNG both belong on pgfoundry, not in the
Mario Weilguni wrote:
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
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???
Mario Weilguni wrote:
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: When can we have sychronous
replication and PITR?.
Performance is not a problem here. People are more interested in
stability and enterprise features such as those I have
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
I'll mention another perspective as a user. I'm actually happier seeing a
relatively minor release come out just before the big changes hit. If 7.5 has
Windows, PITR, nested transactions, etc.
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade for people who just want a safe 7.x
series to upgrade to
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
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
Mike Mascari [EMAIL PROTECTED] writes:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade for
On Mon, 17 May 2004, Mike Mascari wrote:
Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I can't complete by 1 June. Think worse of me if you choose.
...
So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
Personally, Win32, subtransactions and PITR are what we are after.
Second would be inclusion of plPHP and plPerlNG which are arguably the
most widely used languages to connect to PostgreSQL.
plPHP and plPerlNG both belong on
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Most hopefully this is very discouraging! Connection pools are a nice
thing and I have used pgpool recently with great success, for pooling
connections. But attempting to deliver multimaster
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
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
The much I am for pulling stuff that does not belong into core, doing
it just for the fun of cleaning up or trimming doesn't do. One of the
major functions of CVS is that one can tag collections of revisions
that together build a release, a known to be working snapshot of file
revisions. If
Joshua D. Drake wrote:
Just to throw in my .02, plPerlNG won't be ready for testing until mid,
later June either. Then there is also plPHP which although we haven't
had any bug reports still needs some more peer review.
Also we would like to submit our ECPG which includes SET DESCRIPTOR
He is waiting for nested transactions to be committed so he can merge
his work in.
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
I think it should be on gborg.
You mean pgFoundry :)
Chris
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to
I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?
Yes it is a patch against 7.4.2
J
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
On Mon, 17 May 2004, Bruce Momjian wrote:
Server-side languages are tied into the backend even closer than the
user data types. They are best in the core distribution. We didn't put
plR in core because it had a conflicting license.
So, they can live on their own, which is a good thing to
On Mon, 17 May 2004, Jan Wieck wrote:
They are not as independant as one might think. The core support for set
returning functions is required before a PL can do it. Same was with
cursors and same will be with subtransactions being the base for
exception handling. People have been struggling
Marc G. Fournier wrote:
On Mon, 17 May 2004, Mike Mascari wrote:
A quick google of 7.4 Win32 release will reveal that the above was
precisely what was said about 7.4: it would be released to not hold
up important features like the IN optimization and a quick 7.5 would
have Win32 and PITR. It's
On Mon, 17 May 2004, Joshua D. Drake wrote:
I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?
Yes it is a patch against 7.4.2
Will you have one against -HEAD? I believe there have been changes since
7.5 was branched, no? Or have they been
Why is it our responsibility to ensure that though? Shouldn't the
developer (or group of developers) responsible for the
PL/interface/extension be responsible for that?
Let's use plPHP as an example here ... I'm going to guess that it supports
PHP4, which is the 'standard' right now ... what
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?
Yes it is a patch against 7.4.2
Will you have one against -HEAD? I believe there have been changes since
7.5 was
Bruce Momjian said:
Marc G. Fournier wrote:
On Mon, 17 May 2004, Joshua D. Drake wrote:
plPHP and plPerlNG both belong on pgfoundry, not in the core
distribution ...
Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed
to replace plPerl, I was talking with Bruce
Marc G. Fournier wrote:
A quick google of 7.4 Win32 release will reveal that the above was
precisely what was said about 7.4: it would be released to not hold
up important features like the IN optimization and a quick 7.5 would
have Win32 and PITR. It's almost as if a cron job reposts this
On Mon, May 17, 2004 at 17:06:18 -0400,
Greg Stark [EMAIL PROTECTED] wrote:
I'll mention another perspective as a user. I'm actually happier seeing a
relatively minor release come out just before the big changes hit. If 7.5 has
Windows, PITR, nested transactions, etc. especially if I see
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 so complex, they are taking
a lot
On Mon, 17 May 2004, Joshua D. Drake 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
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote:
It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.
I thought the outcome of that discussion was June 15 ?
I think there was no outcome. There was no official
Alvaro Herrera Munoz wrote:
Personally I've been focused on getting subtransactions done and now I think
I'm very close to an acceptable patch, but what has slowed me down the last
time has been lack of feedback from core developers. It was feedback I
needed to figure out the best ways to do
Not being the author, I don't know. And in the case of PITR, the pre-7.4
author is different than the post-7.4 author. However, if I was
personally responsible for holding up the release of a project due to a
feature that I had vowed to complete, I would feel morally compelled to
get it done.
Am Monday 17 May 2004 22:42 schrieb Jan Wieck:
I doubt that. Having deployed several 7.4 databases, the first customers ask
(of course not in technical speech, but in the meaning) when the problem with
checkpoint hogging system down is solved. This is a really serious issue,
especially
Well that seems to be part of the problem. ext3 does not scale well at
all under load. You should probably upgrade to a better FS (like XFS). I
am not saying that your point isn't valid (it is) but upgrading to a
better FS will help you.
Thanks for the info, but I've already noticed
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. ;)
Cheers!
On Tue, 2004-05-18 at 00:16, Mario Weilguni wrote:
Well that seems to be part of the
Bruce Momjian wrote:
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 29 Apr 2004, Tom Lane wrote:
In the first place it's unfair to other developers to make schedule
slips at the last moment, and especially to *plan* to do so.
Isn't it equally unfair to slip the scheduale
Jan Wieck wrote:
We have ARC, the background writer and vacuum delay, and people even ask
me for backports of that (I have one for vacuum delay, but refuse to
make one for the others). How long do you want to delay that being ready
for production? Do you really think people that are
Bruce Momjian kirjutas P, 16.05.2004 kell 22:45:
Jan Wieck wrote:
We have ARC, the background writer and vacuum delay, and people even ask
me for backports of that (I have one for vacuum delay, but refuse to
make one for the others). How long do you want to delay that being ready
for
Hannu Krosing wrote:
Sure, you can work around the lack of a Win32 port with Cygwin, and
maybe use replication in place of PITR, but the big question is are you
hitting a large precentage of users with an enhancement.
I'm not sure that the initial version of PITR will be a good
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any of the other stuff,
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ... Win32 (or
any of the other stuff, like PITR/tablespaces) would be icing on the cake
...
I think we're close enough on win32 to wait for it. It would look bad
for us
On Sun, 2004-05-16 at 23:02, Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to warrant a beta on June 1st, even without Win32 ...
On Sun, 16 May 2004, Bruce Momjian wrote:
Hannu Krosing wrote:
Sure, you can work around the lack of a Win32 port with Cygwin, and
maybe use replication in place of PITR, but the big question is are you
hitting a large precentage of users with an enhancement.
I'm not sure that the
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that we have enough
already to
Marc G. Fournier wrote:
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Sun, 16 May 2004, Bruce Momjian wrote:
I personally don't think Win32 is enough of a new feature either, but
others disagree.
Jan, correct me if I'm wrong ... Jan's point is that
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want more than a vacuum
patch and a new cache replacement policy. I want something big, in
On Mon, May 17, 2004 at 01:53:19 -0300,
Marc G. Fournier [EMAIL PROTECTED] wrote:
Not true ... you just have to fix your definition of what a feature is ...
a feature is an improvement to the system, whether it be new
functionality, or improved performance ... I consider the work Tom did on
On Mon, 17 May 2004, Bruce Momjian wrote:
See my recent email. You are stating that all features are of equal
significance. Basically, the important missing features are also the
ones the require the most work to complete.
Agreed ... and the ones that require the most work to complete
On Mon, 17 May 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
Agreed, but you are a me too, not a huge percentage of our userbase.
How do you know? Have you polled our complete userbase?
Basically, after 6-7 months of development, I want more than a vacuum
patch and a new
On Mon, 17 May 2004, Bruno Wolff III wrote:
On Mon, May 17, 2004 at 01:53:19 -0300,
Marc G. Fournier [EMAIL PROTECTED] wrote:
Not true ... you just have to fix your definition of what a feature is ...
a feature is an improvement to the system, whether it be new
functionality, or
101 - 200 of 248 matches
Mail list logo
