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
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 spell
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 r
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 there
"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 SH
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
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] http:/
> Then if I reindex my DB I have :
>
> NOTICE: --Relation astro--
> NOTICE: Pages 204: Changed 0, reaped 0, Empty 0, New 0; Tup
> 4878: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 324, MaxLen 324;
> Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU
0.04s/0.18u sec.
> NOTICE:
> 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, even
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 mak
> 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 dat
"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.
Do
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
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:
On Mon, 12 Feb 2001, Peter Eisentraut wrote:
> 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 possib
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 l
> -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.
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 expect
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
>> e
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 Ow
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 11 February 2001 06:31
> To: PostgreSQL-development
> Cc: Dave Page; PostgreSQL odbc list; PostgreSQL-patches
> Subject: Re: [ODBC] RE: [PATCHES] Fix for ODBC close
>
>
> OK, I have a pretty good guess about
At 22:25 12/02/01 +0100, Kovacs Zoltan wrote:
>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;
Doesn't happen
"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 'dedic
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 wil
At 18:34 10/02/01 -0500, Bruce Momjian wrote:
>
>Can you give me a few lines to put in sequence.c? There isn't even
>anything in there!
>
I've now put comments on setval, setval_is_called and do_setval. 3 for the
price of one.
Ph
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 prog
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/
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 supp
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 wal_d
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
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 src/backen
> > 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?
>Run it with LC_ALL="
39 matches
Mail list logo
