Tatsuo brought up the an excellent point (that I have been saying for a
long time), that the number of must-fix bugs from previous releases is
shrinking, and the complexity of new features is increasing.
This dictates the that length of our release process should lengthen
over time.
May I also make
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Digging into getting this working on unix, it seems the configure tests
> > > that look at /usr/include are then setting values related to timezone
> > > that don't apply to src/timezone code. Not sure how I
Andrew Dunstan wrote:
> >It's different because we know why we need that one: we understand the
> >cause of the behavior and we therefore can have some confidence that the
> >kluge will fix it (or not, as the case may be). I have zero confidence
> >in looping five times around an "ln" call.
> >
>
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The real issue in my mind is why is "ln" unreliable in mingw? I cannot
see any point in a retry kluge when we do not know what's really going
on.
I'm still trying to find out. But I don't see why this is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 1 May 2004, Bruce Momjian wrote:
> I assume "just fixes" is for bugs not known when going into feature
> freeze, meaning bugs found during testing.
I don't agree with that ... I'd consider the Timezone stuff to be a
feature, since its major changes ... not having it working under Unix is
On Sat, 1 May 2004, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We should also think about what exactly we mean by "feature freeze".
>
> > As I remember, feature freeze means no new features, just fixes, and
> > beta means release of the first beta that we
On Sat, 1 May 2004, Tom Lane wrote:
> In the past there has been little if any daylight between feature freeze
> and start of beta --- in fact, IIRC we did not distinguish these
> concepts at all until the last release or two. It wouldn't be a bad
> idea to try to nail down the terms of discussio
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We should also think about what exactly we mean by "feature freeze".
>
> > As I remember, feature freeze means no new features, just fixes, and
> > beta means release of the first beta that we want for wide testin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We should also think about what exactly we mean by "feature freeze".
> As I remember, feature freeze means no new features, just fixes, and
> beta means release of the first beta that we want for wide testing.
I guess I wasn't clear:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The real issue in my mind is why is "ln" unreliable in mingw? I cannot
>> see any point in a retry kluge when we do not know what's really going
>> on.
> I'm still trying to find out. But I don't see why this is different from
> the
Joe Conway <[EMAIL PROTECTED]> writes:
> However, perhaps *some* of any increase in development time could be
> made up by changing how the beta period is handled.
That would essentially amount to changing our criteria for "start of
beta". How would you like to define it exactly?
We should also
Tom Lane wrote:
> We should also think about what exactly we mean by "feature freeze".
> I've been using it as a shorthand for "we don't think we'll need any
> more major code changes". But depending on how high-level your notion
> of "feature" is, it could be that fairly major code changes could
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Right now there is no distinction between a PREPARE prepared statement
> and a protocol-level one. If we want to have the v3proto's statements
> behave different from PREPARE's, it's just a matter of adding a new
> field into the PreparedStatement.
It
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
And if not 3), is there some autoconf wizard out there who can help do
this properly? It would probably take me many hours to work out, as I
have never touched the beast.
Obviously, or you would know that configure is a generated
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> And if not 3), is there some autoconf wizard out there who can help do
> this properly? It would probably take me many hours to work out, as I
> have never touched the beast.
Obviously, or you would know that configure is a generated file that
there i
On Fri, Apr 30, 2004 at 09:44:52PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Is this expected? If so, why? I'd expect the prepared stmt to be
> > deallocated.
>
> prepare.c probably should have provisions for rolling back its state to
> the start of a failed transac
On Fri, Apr 30, 2004 at 11:36:36PM -0400, Tom Lane wrote:
> Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes:
> > strace'ing the postmaster suggested me that the dbname string in
> > utils/init/postinit.c, the InitPostgres function, is the culprit.
> > In fact, if I apply the following patch to tcop
Bruce Momjian wrote:
Neil Conway wrote:
On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
For me even September 1st does not seem too late. Major version up
bring users pains including backup/restore application
imcompatibilty... IMO to justify those pains we need to give users
major enhancements. Hone
Bruce Momjian wrote:
Neil Conway wrote:
On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
For me even September 1st does not seem too late. Major version up
bring users pains including backup/restore application
imcompatibilty... IMO to justify those pains we need to give users
major enhanceme
Fabien COELHO <[EMAIL PROTECTED]> writes:
> The standard "EVERY" is fine for postgres, the issue is only with
> ANY/SOME.
> Do you think that bool_and should be proposed anyway for homogeneity
> with bool_or?
I think EVERY is actively misleading, because it does *not* imply that
every input is TRU
Neil Conway wrote:
> On 30-Apr-04, at 8:53 PM, Tatsuo Ishii wrote:
> > For me even September 1st does not seem too late. Major version up
> > bring users pains including backup/restore application
> > imcompatibilty... IMO to justify those pains we need to give users
> > major enhancements. Honestl
The really horrid hack below fixes for me a MINGW/MSys problem that
otherwise occurs inconsistently (fails on different links, and pretends
to have succeeded), but reliably (every run at least one link will not
actually have happened).
There are 2 parts - first we loop a few times until we succ
Joshua wrote:
> Why would someone fund a "new" PostgreSQL project when there are several
> viable commercial entities doing the job right now?
Four words: "size of marketing budget".
As a technology guy, it bugs me to acknowledge that. But having lived
through this a few times, it is the way
On Sat, May 01, 2004 at 02:25:01AM -0700, Tony Reina wrote:
> > You might try porting your code to libpqxx, which is C++-native and should
> > make large swathes of this sort of code unnecessary.
> I've seriously considered it (along with the npgsql library), but am
> not really sure as to what t
> > As a "temporary" fix, what about "_ANY" and "_SOME" as aggregate names?
>
> Ick :-(. The use of leading underscores is an ugly C-ism that we should
> not propagate into SQL names.
Ok.
> How about bool_or() and bool_and()? Or at least something based on OR
> and AND? I don't find ANY/ALL t
> You might try porting your code to libpqxx, which is C++-native and should
> make large swathes of this sort of code unnecessary.
>
I've seriously considered it (along with the npgsql library), but am
not really sure as to what the advantage(s) would be considering that
(with the corrections su
> I'm a bit rusty on C++ string mashing, but surely sizeof() is not the
> correct way to determine the number of bytes presently stored in a
> variable-length string?
>
> > * PQputCopyEnd(conn, msg);
Yes, I've had several people mention this and that did the trick.
Thanks to all that replie
> So you are floating the entire thing. I am tired of discussing this.
> You call the freeze and when it is a disaster, you can take the credit.
People seem to _think_ that they can be ready by June 1st. To allow for
unknown problems, why not set a freeze date at June 15?
By May 15 this date ca
29 matches
Mail list logo
