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 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 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
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 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
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,
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 develope
-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
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.
O.
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 ab
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?
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 point. plPHP doesn't need
PHP+PostgreSQL support. Nor does
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
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
Pos
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 D.
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
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 an
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 ther
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 o
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
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
> > spen
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 su
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. I
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 freez
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 a
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 believ
> > 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
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 hi
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" b
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
> 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
> b
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
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 di
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
>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 p
>
> 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 notic
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,
> > espe
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. I
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
n
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
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 of
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
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 longer
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 s
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 rep
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
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 bee
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 abou
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 t
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 al
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 struggli
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
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.
+1-503-667-45
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 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
--
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 DESCRIPTO
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
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
> 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
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 pgfoun
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 s
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
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
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 t
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.
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 ha
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???
Since
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 ha
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
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 which
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 replicati
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 broadcas
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
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
>
> 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, 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 i
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
>
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 o
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 m
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 real
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
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
> 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 broadcast)
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
> >> ...
> >
> >
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 of
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 ... tables
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
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
> > functional
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
> > > pa
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 *wi
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
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 somethi
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 ..
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
> > a
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 su
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, 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
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 to
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,
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 rep
101 - 200 of 254 matches
Mail list logo
