Hi,
I just learned that bison 1.50 was released on Oct. 5th and it indeed
compiles ecpg just nicely on my machine. Could we please install this on
our main machine and merge the ecpg.big branch back into main?
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian
Hello,
which global variable is the path of postgresql binary? such as /usr/local/pgsql/bin
I only find pg_pathbname stand for postgres full pathname.
thank you in advance.
Jinqiang Han
---(end of broadcast)---
TIP 1: subscribe and
On Wed, 09 Oct 2002 10:00:03 +0200, I wrote:
here is an implementation of a set of user types: char3, char4,
char10.
New version available. As I don't want to spam the list with various
versions until I get it right eventually, you can get it from
Can we please hold off until bison 1.50 becomes a defacto? It will be a
matter of weeks before distros offer this as an upgrade package let
alone months before distros offer this as a standard. Seems like these
changes are ideal for a release after next (7.5/7.6) as enough time will
of gone by
On 10 Oct 2002 at 15:30, Manfred Koizar wrote:
On Wed, 09 Oct 2002 10:00:03 +0200, I wrote:
here is an implementation of a set of user types: char3, char4,
char10.
New version available. As I don't want to spam the list with various
versions until I get it right eventually, you can get
Greg Copeland [EMAIL PROTECTED] writes:
Can we please hold off until bison 1.50 becomes a defacto?
We don't have a whole lot of choice, unless you prefer releasing a
broken or crippled ecpg with 7.3.
In practice this only affects people who pull sources from CVS, anyway.
If you use a tarball
Oh, that's right. I had forgotten that it wasn't for general PostgreSQL
use. Since it's a ecpg deal only, I guess I remove my objection.
Greg
On Thu, 2002-10-10 at 09:18, Tom Lane wrote:
Greg Copeland [EMAIL PROTECTED] writes:
Can we please hold off until bison 1.50 becomes a defacto?
Here are the open items. There are only a few major ones left. I would
like to get those done so we can shoot for a final release perhaps at
the end of October.
---
P O S T G R E S Q L
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I was looking for consistency so we could have things ready if we
tighten up in 7.4. I believe someone volunteered to fix them all so I
figured we should do that.
Someone did volunteer, but I haven't seen results. My point is
On 10 Oct 2002, Neil Conway wrote:
Well, I'd assume any C library / compiler of half-decent quality on
any platform would provide assembly optimized versions of common
stdlib functions like memset().
While playing around with memset() on my machine (P4 running Linux,
glibc 2.2.5, GCC
Greg Copeland wrote:
-- Start of PGP signed section.
Can we please hold off until bison 1.50 becomes a defacto? It will be a
matter of weeks before distros offer this as an upgrade package let
alone months before distros offer this as a standard. Seems like these
changes are ideal for a
Gavin Sherry [EMAIL PROTECTED] writes:
On 10 Oct 2002, Neil Conway wrote:
Compiled with '-DBUFFER_SIZE=256 -O2', I get the following results in
seconds:
MemSet(): ~9.6
memset(): ~19.5
__builtin_memset(): ~10.00
I ran the same code. I do not understand the results you go.
Bruce Momjian [EMAIL PROTECTED] writes:
Schema handling - ready? interfaces? client apps?
Drop column handling - ready for all clients, apps?
How will delaying 7.3 remedy either of these issues?
Get bison upgrade on postgresql.org for ecpg only (Marc)
Now that bison 1.50 is out, this should
Neil Conway wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Schema handling - ready? interfaces? client apps?
Drop column handling - ready for all clients, apps?
How will delaying 7.3 remedy either of these issues?
Get bison upgrade on postgresql.org for ecpg only (Marc)
Now that
Denis A Ustimenko wrote:
Hello Bruce!
You have patched fe-connect.c and dropeed out one check in line 1078:
while (rp == NULL || remains.tv_sec 0 || (remains.tv_sec == 0 remains.tv_usec
0))
---
while (rp == NULL || remains.tv_sec 0 || remains.tv_usec 0)
As I understand it is
OK, I have applied the following patch which should fix the problem by
preventing tv_sec from becoming negative.
---
Bruce Momjian wrote:
Denis A Ustimenko wrote:
Hello Bruce!
You have patched fe-connect.c and
Barry Lind wrote:
Did anything come of this discussion on whether SET initiates a
transaction or not?
SET does not start a multi-statement transaction when autocommit is off.
In summary what is the right way to deal with setting autocommit in clients?
I guess just 'set autocommit to on'
17 matches
Mail list logo
