On Mon, 12 Feb 2001, Christopher Kings-Lynne wrote:
I just got this error message in 7.0.3:
ERROR: to_char/to_number(): not unique decimal poit.
Might want to ensure it's correctly spelled in 7.1
Hmm, you are right. But I don't want prepare a patch with one
char.
Hackers, can
Hello,
I just saw (or better to say waspointed to) the following bug in Bug tracking
tool submitted yesterday: pgsql 7.0.2 cursor bug.
I have exactly the same trouble... Until I free cursor daemon grows...
I have this in plain 7.0.3. Any comments?
--
Sincerely Yours,
Denis Perchine
Done.
On Mon, 12 Feb 2001, Christopher Kings-Lynne wrote:
I just got this error message in 7.0.3:
ERROR: to_char/to_number(): not unique decimal poit.
Might want to ensure it's correctly spelled in 7.1
Hmm, you are right. But I don't want prepare a patch with one
char.
On Mon, 12 Feb 2001, Bruce Momjian wrote:
Done.
Thanks!
On Mon, 12 Feb 2001, Christopher Kings-Lynne wrote:
I just got this error message in 7.0.3:
ERROR: to_char/to_number(): not unique decimal poit.
Might want to ensure it's correctly spelled in 7.1
Hmm,
Hi !!
I am trying to install Postgresql-7.0.3 on the solaris 5.6 machine and
i am trying to configure it as a user and not as a root because i don't
have root access as it is my computer science departmental machine.
when i run a make it gives the following error:
gmake[3]: Leaving directory
Great! :)
It might also clean up something that I've been fighting against for
awhile: when I include files needed for SPI, it drags also a lot of other
garbage in, which conflicts with other things (namely, trying to get a
file to simultaneously include SPI and perl headers is impossible).
I
Hi all,
I'm starting to program with the SPI interface with PG 7.0.3. I can get
everything to work up until I use SPI_exec (successfully) using a query
like 'SELECT foobar, baz1 from test1'.
The return code from SPI_exec indicates SPI_OK_SELECT and the variable
SPI_processed is 2 (meaning
"Ross J. Reedstrom" wrote:
Does anyone object if I modify pgaccess so that it always specifies the
full path to the library? That seems like it'd be a good idea even on
OSes without this quirk, because it'd ensure getting the matching
version of libpgtcl and libpq even if your
Amit Sharma writes:
libpq/SUBSYS.o(.text+0x5038): undefined reference to `__inet_ntoa'
I was getting the same trouble with installing Apache WebServer in my
account and had to go and modify the "makefiles" to include
-lbind option in them. Do i have to do the same thing here as well, i
I see the new PL/PgSQL command:
GET DIAGNOSTICS
This seems like a poorly-worded command to me. It is meant to return
the number of rows affected by a previous query, right?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
On Fri, Feb 09, 2001 at 12:04:08PM -0500, Bruce Momjian wrote:
I see the new PL/PgSQL command:
GET DIAGNOSTICS
This seems like a poorly-worded command to me. It is meant to return
the number of rows affected by a previous query, right?
Among other things, eventually. You get to
Bruce Momjian writes:
I see the new PL/PgSQL command:
GET DIAGNOSTICS
This seems like a poorly-worded command to me. It is meant to return
the number of rows affected by a previous query, right?
That's how SQL wants it.
--
Peter Eisentraut [EMAIL PROTECTED]
Due to the urgency, I resend my mail about pg_dump output:
In 7.0.2 I got
INSERT INTO foo (field) VALUES ('Hello,\012world!');
In 7.1beta4 I get
INSERT INTO foo (field) VALUES ('Hello,
world!');
I am using these switches: -a, -c, -n, -d or -D.
Is it possible to add a switch to pg_dump to
before this manipulmation, pg_log = 1.073.741.824
O, your system reached max transaction ID -:(
and xmin = 4982339
And now all tuples with xmin ~500 are invisible.
One way to restore data could be hack vacuum to update
xmin of all valid tuples to 512, vacuum all tables,
dump data,
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
before this manipulmation, pg_log = 1.073.741.824
O, your system reached max transaction ID -:(
That's two reports now of people who have managed to wrap around the XID
counter. It doesn't seem that hard to do in a heavily used database.
Does
Kovacs Zoltan writes:
In 7.0.2 I got
INSERT INTO foo (field) VALUES ('Hello,\012world!');
In 7.1beta4 I get
INSERT INTO foo (field) VALUES ('Hello,
world!');
Is it possible to add a switch to pg_dump to make it possible getting the
old output. Where can I balance it in the source if I'd
So there are two issues here which I hope to clarify: scoping
on joins, and NATURAL and USING join column sets.
I've been looking some more at this business, and I have found one of
the reasons that I was confused. The SQL92 spec says (6.3 syntax rule
2)
2) Case:
a) If
Peter Eisentraut [EMAIL PROTECTED] writes:
Btw., if I select the default COPY output, pg_dump seems to drop
non-printable characters like '\001'.
You sure? They're there in my output. COPY doesn't turn them into
escape sequences, if that's what you were expecting.
[EMAIL PROTECTED] wrote:
I have applied the following patch to properly exit ODBC. I also
patched the ODBC makefile so it links under BSD/OS. The -Bsymbolic
under BSD/OS is very harsh under BSD/OS, requiring all symbols even in
libc and crt1.o to be resolved before creating the shared
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: 10 February 2001 05:46
To: PostgreSQL odbc list; PostgreSQL-patches
Cc: PostgreSQL-development
Subject: [PATCHES] Fix for ODBC close
I have applied the following patch to properly exit ODBC.
Snip
I
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Btw., if I select the default COPY output, pg_dump seems to drop
non-printable characters like '\001'.
You sure? They're there in my output. COPY doesn't turn them into
escape sequences, if that's what you were expecting.
If
Tom Lane writes:
What are you using to inspect the file?
Ugh... :-/
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Btw., if I select the default COPY output, pg_dump seems to drop
non-printable characters like '\001'.
You sure? They're there in my output. COPY doesn't turn them into
escape
By the way, I get each sequence twice in pg_dump output... In psql:
CREATE TABLE x (y SERIAL);
Then running pg_dump with switches -xacnOD, I get:
--
-- Selected TOC Entries:
--
DROP SEQUENCE x_y_seq;
DROP SEQUENCE x_y_seq;
--
-- TOC Entry ID 1 (OID 2625010)
--
-- Name: x_y_seq Type: SEQUENCE
"Martin A. Marques" [EMAIL PROTECTED] writes:
test=# CREATE TABLE dedicacion (
test(#id_dedi SERIAL UNIQUE,
test(#nombre_dedi CHAR(10) UNIQUE
test(# );
NOTICE: CREATE TABLE will create implicit sequence 'dedicacion_id_dedi_seq'
for SERIAL column
At 18:49 12/02/01 +0100, Kovacs Zoltan wrote:
In 7.0.2 I got
INSERT INTO foo (field) VALUES ('Hello,\012world!');
In 7.1beta4 I get
INSERT INTO foo (field) VALUES ('Hello,
world!');
I have modified formatLiteralString to accept an arg that tells it how to
handle LF TAB. Now, it will encode
There is a serious problem with the PostgreSQL locale support on
certain platforms and certain locale combo. That is: simply ordering,
indexes etc. are broken because strcoll() does not work. Example
combo includes: RedHat 6.2J(Japanese localized version) + ja_JP.eucJP
locale. Here is a test
On Mon, Feb 12, 2001 at 09:59:37PM -0500, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
I know this is not PostgreSQL's fault but the broken locale data on
certain platforms. The problem makes it impossible to use PostgreSQL
RPMs in Japan.
I'm looking for solutions/workarounds
Tatsuo Ishii [EMAIL PROTECTED] writes:
I know this is not PostgreSQL's fault but the broken locale data on
certain platforms. The problem makes it impossible to use PostgreSQL
RPMs in Japan.
I'm looking for solutions/workarounds for this problem.
Build a set of RPMs without locale support?
On Sun, 11 Feb 2001, Vadim Mikheev wrote:
Please try to restart with option wal_debug = 1 so postmaster log
will be more informative and send this log me.
I enabled 'wal_debug=1' via both the -c command line option and
(seperately) via ./data/postgresql.conf, as well as setting
On Mon, 12 Feb 2001, Ryan Kirkpatrick wrote:
One other wrench to thrown into the works... The kernel on this
machine is 2.2.18 with the patches listed at www.linuxraid.org applied. I
have a feeling that the linux-security patches mentioned on that page may
be giving pgsql heartburn on
Ryan Kirkpatrick [EMAIL PROTECTED] writes:
#2 0x20dc71 in abort () from /lib/libc.so.6
#3 0x8080495 in XLogFileOpen ()
Hm. Evidently it's failing to open the xlog file, but the code is set
up in such a way that it dies before telling you why :-( Take a look
at XLogFileOpen in
32 matches
Mail list logo
