Hi,
It seems the timestamp.c patch to getg around the SCO optimizer bug did'nt
get in beta1
Is it normal?
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE
AIUI, the issue is statements like:
# select numeric(6,3) '5.6';
Bison can't look far enough ahead to determine whether the numeric is a
type or a function. However, the desired grammer itself is not
ambgiuous, it's just that Bison is not smart enough to make it work. It
works now only because
Hi!
During testing of 8.1 I found that using pg_dumpall (-g) against a live
8.0 install that has at least one GROUP defined results in the following
warning while it creates the CREATE ROLE statements in the dump:
row number 0 is out of range 0..-1
To reproduce the problem it is enough to
[EMAIL PROTECTED] writes:
Our friendly psql complains that pg_shadow is a view:
psql:filename:11: ERROR: cannot delete from a view
HINT: You need an unconditional ON DELETE DO INSTEAD rule.
Yeah, this is on the open-items list; the DELETE FROM is broken (and
was always a pretty bogus
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
During testing of 8.1 I found that using pg_dumpall (-g) against a live
8.0 install that has at least one GROUP defined results in the following
warning while it creates the CREATE ROLE statements in the dump:
row number 0 is out of range 0..-1
I poked around this one. The SSL locking documentation is at:
http://www.die.net/doc/linux/man/man3/crypto_set_id_callback.3.html
The description isn't clear. When they talk about locking_function()
and id_function(void), they are talking about arguments to the SSL
functions listed above,
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
During testing of 8.1 I found that using pg_dumpall (-g) against a live
8.0 install that has at least one GROUP defined results in the following
warning while it creates the CREATE ROLE statements in the dump:
row number 0 is out
Awhile back I wrote:
Hmm, I don't see that symptom, but I do see some strange stuff building
PG CVS tip on a fully-up-to-date (10.4.2) OS X machine.
...
Second, at exit from an interactive psql session,
regression=# \q
could not save history to file /Users/tgl/.psql_history: Invalid
The basic issue with SSL is that it wants some unique
identifier for threads. They really should have defined the
function to take pthread_t rather than unsigned long because
pthreads doesn't really give us a useful way to get an
They absolutely should not have done that. That would've
Magnus Hagander wrote:
The basic issue with SSL is that it wants some unique
identifier for threads. They really should have defined the
function to take pthread_t rather than unsigned long because
pthreads doesn't really give us a useful way to get an
They absolutely should not
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 28 August 2005 18:19
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Win32 Thread safetyness
I poked around this one. The SSL locking documentation is at:
Bruce Momjian pgman@candle.pha.pa.us writes:
Magnus Hagander wrote:
Also, there doesn't seem to be a good way for users to know
if libpq or ecpg was compiled to be thread-safe.
Right. A runtime function for this might be a good thing? Like bool
PQisThreadSafe() or such?
Yes, and a flag
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, and
encounter strange problems from time to time.
After dropping and recreating the slony schema, all changes committed
and all backends in IDLE state, I'm getting
relation with OID xxx does not exist when I'm trying to add a
Dave Page wrote:
So, we might be able to get away without this on Win32, or perhaps the
pthread_self().p is a valid unique identifier for Win32 threads and
pthreads.
Right.
How is this pthread_self() call working on Win32 now? Is pthreads a
requirement for libpq threading on Win32?
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Magnus Hagander wrote:
Also, there doesn't seem to be a good way for users to know
if libpq or ecpg was compiled to be thread-safe.
Right. A runtime function for this might be a good thing? Like bool
PQisThreadSafe() or
I have the following conferences scheduled:
Sept 7-10, Sri Lanka
Sept 17, New York City
October 17-20, Amsterdam
Information is on the PostgreSQL Events list and my home page. I also
have a possible Armenia trip for early October, and Mexico for
mid-November.
--
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 28 August 2005 22:56
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Win32 Thread safetyness
Well, actually I tried to run configure --enable-thread-safety on a
MinGW platform and
Patch applied. Autoconf run. Thanks.
---
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 28 August 2005 22:56
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Yeah, I think it's a timing thing on when the fix was committed and when
Beta1 was pulled.
It will be in the next beta/release based on the commit I saw.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US
* optional interface which sends a row typeoid along with each row in a result
set
Oh, and 'select rowid, * from table' which returns special rowid column
that just incrementally numbers each row.
Chris
---(end of broadcast)---
TIP 6:
Folks,
I've noticed that \df doesn't do quite what it might when a function
is created with named input parameters. Please find enclosed a patch
against CVS TIP that does this better.
On a slightly related note, I've noticed that psql isn't backward
compatible. I know that it's *very* late to
David Fetter [EMAIL PROTECTED] writes:
On a slightly related note, I've noticed that psql isn't backward
compatible.
We have never expected psql's \d commands to work against older server
versions, and two months after feature freeze isn't the time to start
making that happen.
22 matches
Mail list logo
