Nathan Myers wrote:
[ ... ]
Not true. There are Debian source packages,
Where are they ? I'm *quite* interested !
and taking the source
package from Debian 2.x, x2 (woody/sid), you can easily build it
on Debian 2.2 (potato).
In fact, it
Emmanuel Charpentier wrote:
Oliver Elphick seems awfully busy and once said that 7.1 required a
*lot* of packaging ... Better not bug him right now ...
I'm working on it at the moment.
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight
On Wed, Jan 17, 2001 at 10:34:45PM +0100, Emmanuel Charpentier wrote:
Nathan Myers wrote:
Not true. There are Debian source packages,
Where are they ? I'm *quite* interested !
and taking the source
package from Debian 2.x, x2 (woody/sid),
Re
On Tue, 16 Jan 2001, Tatsuo Ishii wrote:
The encoding of your databases are all UNICODE. So you need to input
data as UTF-8 in this case. I guess you are trying to input ISO-8859-1
encoded data that is the source of the problem. Here are possible
solutions:
1) input data as UTF-8
:)
2)
On Wed, Jan 17, 2001 at 01:40:58AM +0100, Rehak Tamas wrote:
3) upgrade to 7.1 that has the capability to do an automatic
conversion between UTF-8 and ISO-8859-1.
i like to use deb packages and to use 7.1 i would have to upgrade
to woody (or even sid)...
Not true. There are Debian
Hello
On Mon, 15 Jan 2001, Tatsuo Ishii wrote:
Can you show me your database name and the output from 'psql -l'?
yes, here are the output:
datname |datdba|encoding|datpath
-+--++-
template1|31| 5|template1
map
yes, here are the output:
datname |datdba|encoding|datpath
-+--++-
template1|31| 5|template1
map | 1003| 5|map
helyes | 1003| 5|helyes
i found that if i put a space behind the
Hello
i don't know, whether it is a real bug or what, has been fixed or not, but
i can't find any info about it:
i try to fill my table from a file using copy from stdin and postgresql
corrupt the table. This happen if before the tab or end of line there
is word that has a non-standard letter
Rehak Tamas [EMAIL PROTECTED] writes:
i try to fill my table from a file using copy from stdin and postgresql
corrupt the table. This happen if before the tab or end of line there
is word that has a non-standard letter like o with accent and then an
ordinary lette [a-z]. and now i reproduced
Sorry to folowup on my own post
Problem solved: real and test db don't run on the same machine.
On the test one, postgres had the same uid as pg_shadow.usesysid for the
user...
Sorry to have bothered you all.
Reagrds
On Wed, 10 Jan 2001, Olivier PRENANT wrote:
Hi,
I just recompiled
On Wed, 10 Jan 2001, Olivier PRENANT wrote:
Hi,
I just recompiled 7.1 beta from current CVS today.
I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that
psql -l shows 2 template0 and template1...
Template0 and template1 belong to user postgres and to an other who
Hi,
it's obviously there is a query plan optimizer bug, if int2 type used in fields,
the plan generator just use sequence scan, it's stupid, i am using PG7.03,
this is my log file:
-
stock# drop table a;
DROP
stock# create table a(i int2, j int);
CREATE
stock# create unique index idx_a
At 10:46 AM 11/22/00 +0800, xuyifeng wrote:
Hi,
it's obviously there is a query plan optimizer bug, if int2 type used in
fields,
the plan generator just use sequence scan, it's stupid
Have you checked this with real data after doing a VACUUM ANALYZE?
- Don Baccus, Portland OR [EMAIL
I did VACUUM ANALYZE, there is no effect.
XuYifeng
- Original Message -
From: Don Baccus [EMAIL PROTECTED]
To: xuyifeng [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, November 22, 2000 10:51 AM
Subject: Re: [HACKERS] query plan optimizer bug
At 10:46 AM 11/22/00 +0800
"xuyifeng" [EMAIL PROTECTED] writes:
stock# create table a(i int2, j int);
stock# create unique index idx_a on a(i, j);
stock# explain select * from a where i=1 and j=0;
psql:test.sql:4: NOTICE: QUERY PLAN:
Seq Scan on a (cost=0.00..25.00 rows=1 width=6)
The constant "1" is implicitly
Matthew [EMAIL PROTECTED] writes:
The correct fix is CommandCounterIncrement() in the DROP USER loop,
so that later iterations can see the changes made by prior iterations.
Since postgre now suppport referential integrity and cascading deletes,
wouldn't it make more sense to use that code to
Matthew [EMAIL PROTECTED] writes:
Anyway, any comments? Can anyone else repeat this? I hope this is easy to
fix. I guess the quick fix is to disallow multiple users to be specified
in the drop user command.
The correct fix is CommandCounterIncrement() in the DROP USER loop,
so that later
I think we have found a bug in postgresql 7.0.2. If I'm right then a fix
for this should probably be added to 7.0.3 also. Anyway without further
adieu:
I have attached detail of my session at the end of this email, but the
summary is as follows.
If I run the following commands my
Matthew [EMAIL PROTECTED] writes:
I think we have found a bug in postgresql 7.0.2.
Bug confirmed --- on a compilation with Asserts enabled, this sequence
causes an assert failure during update of pg_group_name_index in the
DROP USER command, in both 7.0.* and current sources. I ran out of
501 - 519 of 519 matches
Mail list logo
