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. Honestly I don't understand why we should
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 can
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 replied.
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
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 to be
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 the
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 it
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
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. Honestly I
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 TRUE. The
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
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.
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
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 transaction ...
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 is no
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
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 just
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 still
be
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
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 kludge we
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: what I
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 testing.
I guess
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 discussion a
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 want for wide
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 a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
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.
Even
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 am going to
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
30 matches
Mail list logo
