At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
I think the cleanest solution is probably to add a state flag indicating
whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
(I didn't think this would work, because I thought libpq would allow
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote:
I think the cleanest solution is probably to add a state flag indicating
whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
Not exactly --- the way
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I think the cleanest solution is probably to add a
state flag indicating whether ParseComplete should generate a PGresult
or not.
Adding a flag is going to be enough for synchronous queries. But it
seems like it has no
Bruce Momjian [EMAIL PROTECTED] writes:
I think we are getting closer to a final release.
...
* synchonize supported encodings and docs
Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
http://archives.postgresql.org/pgsql-hackers/2004-10/msg00142.php
I'm anxious to see
Greg Stark [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
* synchonize supported encodings and docs
Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
No ... does it look like it?
I'm not sure whether the patch he sent is adequate, I looked at it
myself and
refactored later.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Saturday, October 16, 2004 3:41 PM
To: Greg Stark
Cc: [EMAIL PROTECTED]; Abhijit Menon-Sen
Subject: Re: [HACKERS] Nearing final release?
Greg Stark [EMAIL
It seems most logical to me to break the fundamental operations into:
1. Prepare to create the compiled query plan
2. Describe to bind the query input/output parameters
3. Execute to produce a result set
Or equivalent functionality. Then, you can bind all three parts into
one operation if you
Subject: [HACKERS] Nearing final release?
o fix MSVC build to export SSL symbols
That should be OK now that you've applied Magnus' libpq patch that
standardises the libpq exports and adds a dummy PQgetssl() to non-SSL
builds.
Regards, Dave
---(end
Sean Chittenden wrote:
It seems most logical to me to break the fundamental operations into:
1. Prepare to create the compiled query plan
2. Describe to bind the query input/output parameters
3. Execute to produce a result set
Or equivalent functionality. Then, you can bind all
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
* synchonize supported encodings and docs
Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
No ... does it look like it?
Er, oops. I quoted the wrong line.
I think we are getting closer to a final release. I haven't seen many
_major_ failures in a few weeks, and the open items list is shrinking. I
would like us to make a concentrated effort to address or fix all the
open items by November 1 and consider a final 8.0 release during November.
We see that the win32 version of PostgreSQL sometime does not respond
to pgbench -S running on Linux. Try something like:
pgbench -h windows_host -S -c 128 -t 1000 your_database
on Linux/FreeBSD/UNIX or whatever.
--
Tatsuo Ishii
I think we are getting closer to a final release. I haven't seen
12 matches
Mail list logo