On Thursday 08 January 2004 15:32, Earnshaw, Peter J wrote:
I currently have postgresql-7.3.4-3.rh19 installed and need to compile with
options: --enable-multibyte and --enable-unicode. I also need to compile up
the JDBC drivers --with-java to create the postgresql.jar. Do I need to
un-install
Am Donnerstag, 8. Januar 2004 16:32 schrieb Earnshaw, Peter J:
I currently have postgresql-7.3.4-3.rh19 installed and need to compile with
options: --enable-multibyte and --enable-unicode.
These options do not exist in the 7.3 series. (They are the default
behavior.)
I also need to compile
Hello!
I am planning to use unique IDs in the little system I am building. Now
being more than a little paranoid (and having no idea about expected loads),
I am wary of using int4 as a basis for uids (for the fear of ever running
out of them).
So the logical choice would be int8, right?
Hello
We're experiencing weird behaviours with both Postgres 7.3.x and 7.4.1
versions, relating to views based on views including fields based upon
plpgsql functions. Attached is a .sql file showing our problems, from a
co-worker who doesn't have immediate access to this mailing list.
Here's
Sergey Olefir wrote:
So the logical choice would be int8, right? Unfortunately quite wrong.
Statement of the form: SELECT * FROM table WHERE id=1
will never use index for id (assumming id is int8) since '1' is of type
int4. This is confirmed both by documentation and SQL EXPLAIN (after set
On Fri, Jan 09, 2004 at 04:11:08AM -0600, D. Dante Lorenso wrote:
Sergey Olefir wrote:
So the logical choice would be int8, right? Unfortunately quite wrong.
Statement of the form: SELECT * FROM table WHERE id=1
will never use index for id (assumming id is int8) since '1' is of type
int4.
Using arrays I came across some strangenesses. Probably this is well
known, but I couldn't find mentions of it.
I am under the impression that this should be an error. Am I wrong?
EXAMPLE 1:
maint=# select ('{{1,2,3},{4,5,6}}'::int[])[1][1:3];
int4
---
{{1,2,3}}
(1 row)
Shouldn't
Tom Lane writes:
Paul Janssen writes:
Can anyone help me out with the following situation:
(a) a single query with 550 id's in the IN-clause resulting into 800+
seconds;
(b) 550 queries with a single id in the IN-clause resulting into
overall time of 60 seconds;
The table consists of
Hi!
Can't get the
sudo -u user1 /usr/local/bin/pg_dump db1 | /usr/local/bin/psql -U user2
-h host2 db2
to work.
Only thing that happens is that I get multiple passwordprompts, and
then I gets told that the password is incorrect
Would appreciate quick help,
sincerely
Victor Spng Arthursson
hello
i have been used RH for over 5 yrs and some of our server are going to
RH AS and most of our workstations are moving to fedora
i have fedora servers in testing right now(PG 7.4 and 7.3) and have not
seen any major problems
as for extended rh9,7.. support you can check out
psql returns:
Invalid UNICODE character sequence found(0xc000) in a valid query.
Steps to reproduce:
1. createdb -E UNICODE mydbname.
2. create a table with some varchar inside, we will query on this field.
Example:
CREATE TABLE auth_role
(
rol_id int4 not null default
Title: Message
Hi,
I need to know if
there is a way to defer ordisable a unique index on a table during an
update. One way would be to set indisunique to false, perform update and then
set to true. But, this seems to be an ugly solution.
I've posted a similar message 6 months ago and at
On Mon, 5 Jan 2004 [EMAIL PROTECTED] wrote:
Hello,
I am new in PostgreSQL world coming from Oracle.
I have created two databases using command line as manual has suggested.
For instance I have done like the following:
createdb tanya
createdb eps
Now I would like to stop my tanya database
David Helgason [EMAIL PROTECTED] writes:
EXAMPLE 1:
maint=# select ('{{1,2,3},{4,5,6}}'::int[])[1][1:3];
int4
---
{{1,2,3}}
(1 row)
Shouldn't this have been just {1,2,3} ?
Nope. It's equivalent to (...)[1:1][1:3]. See section 8.10.3 Accessing
Arrays in the current
Oleg Lebedev wrote:
Hi,
I need to know if there is a way to defer or disable a unique index on a
table during an update. One way would be to set indisunique to false,
perform update and then set to true. But, this seems to be an ugly
solution.
I've posted a similar message 6 months ago
So, does it mean that the only way to disable the index is to drop and
recreate it? What about setting indisunique to false temporarily?
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 10:19 AM
To: Oleg Lebedev
Cc: [EMAIL PROTECTED]
Scott,
Though there is not exact match, you may consider that:
Oracle instance = Postgres cluster
Oracle schema = Postgres database.
But there is a schema concept in Postgres that is pretty similar to the one in Oracle.
( Actually, I think there is a lack of database concept in Oracle.)
That's
So, does it mean that the only way to disable the index is to drop and
recreate it? What about setting indisunique to false temporarily?
I am just curious... why would you want to defer a unique constraint?
Sincerely,
Joshua Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL -
For my particular case, word repetition shouldn't be relevant in determining
the rank of a document. If I strip() the vector, I loose what relevance
proximity and weight add to the rank. It seems impossible, yet I ask anyway: Is
it possible to eliminate the second (third, fourth, fifth, etc.)
Oleg Lebedev wrote:
So, does it mean that the only way to disable the index is to drop and
recreate it? What about setting indisunique to false temporarily?
Not sure. I seem to remember a way someone got around this, but can't
remember the details.
--
Bruce Momjian|
Basically, swapping values of columns involved in a unique index causes
the problem.
Example:
I wrote a synchronization script that syncs data between multiple
databases. It retrieves primary key information from the system tables,
joins remote tables and updates corresponding values.
Suppose
Joshua D. Drake wrote:
So, does it mean that the only way to disable the index is to drop and
recreate it? What about setting indisunique to false temporarily?
I am just curious... why would you want to defer a unique constraint?
I remember now --- if you do:
UPDATE tab SET
I see that it works for this simple case.
Check my previous email for a more complex example.
Thanks.
Oleg
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 10:45 AM
To: Joshua D. Drake
Cc: Oleg Lebedev; [EMAIL PROTECTED]
Subject: Re:
Chris Gamache wrote:
For my particular case, word repetition shouldn't be relevant in determining
the rank of a document. If I strip() the vector, I loose what relevance
proximity and weight add to the rank. It seems impossible, yet I ask anyway: Is
it possible to eliminate the second (third,
Hello everybody!
Does someone know how to build hierarchical queries to the postgresql?
I have a table with tree in it (id, parent)
and need to find a way from any point of the tree to any other point.
And i would like to have a list of all steps from point A to point B
to make some changes on
There's a patch to mimic Oracle's CONNECT BY queries. You can get it
at the Postgres Cookbook site:
http://www.brasileiro.net/postgres/cookbook.
(although it seems to be down at the moment...)
On Jan 9, 2004, at 2:05 PM, [EMAIL PROTECTED] wrote:
Hello everybody!
Does someone know how to build
On Friday 09 January 2004 19:16, Andrew Rawnsley wrote:
There's a patch to mimic Oracle's CONNECT BY queries. You can get it
at the Postgres Cookbook site:
http://www.brasileiro.net/postgres/cookbook.
I believe I saw an announcement on freshmeat about a patch for the source to
allow
I'm running Postgres 7.1.3, and just started having a problem where my
dynamic site is going down (read-only DB, with no writes happening to the
DB) regularly (every other day). I have no idea whay this is happening,
and my search of the FAQ's and mail list don't bring up anything. i've
attached
Sergey Olefir [EMAIL PROTECTED] writes:
Unfortunately neither of them seem to be portable (for example, the one with
single quotes fails if I create PreparedStatement in Java:
con.prepareStatement(SELECT * FROM table WHERE id='?'); apparently Java
doesn't parse question mark inside quotes).
On Fri, 9 Jan 2004, Aurangzeb M. Agha wrote:
Right! Thus my quandry.
Re inodes, how can I check this? But why would this be? Is Postgres
sucking up inodes just sitting there as a read-only DB?
If you are out of inodes, I seriously doubt it is Postgresql's fault, as
you seem to be
I would suspect some *other* service is using the 4G for transient
storage every now and again, and it just so happens that Pg is getting
tripped up.
What else does this machine run ?
regards
Mark
Nigel J. Andrews wrote:
On Fri, 9 Jan 2004, Aurangzeb M. Agha wrote:
Here's the output
On Fri, Jan 09, 2004 at 12:07:25PM -0800, Kragen Sitaker wrote:
snip
Not really related to your problem, but given you're in a transaction, why
do you need to lock anything? What's wrong with:
The daemon that gets this error does the following every 15 seconds:
- start a transaction
- delete
On Fri, 9 Jan 2004, scott.marlowe wrote:
On Fri, 9 Jan 2004, Aurangzeb M. Agha wrote:
Right! Thus my quandry.
Re inodes, how can I check this? But why would this be? Is Postgres
sucking up inodes just sitting there as a read-only DB?
If you are out of inodes, I seriously doubt
On Sat, 10 Jan 2004, Nigel J. Andrews wrote:
And a common culprit is whatever is being used for usenet caching/serving...or
ordinary mail which is just accumulating in /var/mail (or whereever).
Sheesh. Did I really put ordinary mailbox mail in the uses up inodes category?
I should taken out
On Fri, Jan 09, 2004 at 06:19:00PM -0500, Tom Lane wrote:
Kragen Sitaker [EMAIL PROTECTED] writes:
ERROR: Cannot insert a duplicate key into unique index pg_class_relname_nsp_index
We've been getting this error in our application every once in a while
--- typically once an hour to once a
On Sat, Jan 10, 2004 at 11:20:11AM +1100, Martijn van Oosterhout wrote:
Not really related to your problem, but given you're in a transaction, why
do you need to lock anything? What's wrong with:
The daemon that gets this error does the following every 15 seconds:
- start a transaction
-
Tom Lane wrote:
Hmm. I'm not aware of any 7.4 bug fix that would affect such a thing,
so I wouldn't want to bet that 7.4 has really solved the issue.
Digging in the 7.3.2-to-7.3.4 change logs, I see one potentially
relevant change:
The only thing I can think of is the fix for splitting the
unsubscribe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Digging in the 7.3.2-to-7.3.4 change logs, I see one potentially
relevant change:
The only thing I can think of is the fix for splitting the first btree
page.
I paused on that too, but I don't see how it could apply, unless they
were
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Digging in the 7.3.2-to-7.3.4 change logs, I see one potentially
relevant change:
The only thing I can think of is the fix for splitting the first btree
page.
I paused on that too, but I don't see how it could
On Tue, 6 Jan 2004, Rajesh Kumar Mallah wrote:
Hi,
Could you please tell how the did you mean feature
was implemented when the serach term has a typo.
it's based on trigrams similarity and words statistics.
The search engine is good .
Regds
mallah.
Oleg Bartunov wrote:
Hi there,
Kragen Sitaker [EMAIL PROTECTED] writes:
We'll run the experiment again. Should we try 7.3.3 too?
No, I don't think 7.3.3 is likely to behave differently from 7.3.4
as far as this goes. What would actually be interesting is whether
you can make 7.4 fail.
Well, it's possible the daemon could
Laurent Perez [EMAIL PROTECTED] writes:
We're experiencing weird behaviours with both Postgres 7.3.x and 7.4.1
versions, relating to views based on views including fields based upon
plpgsql functions.
There are a couple of things going on here. The principal one is a
limitation that
Hey folks,
I've been migrating a content management system from MS SQL Server 7 over
to PostgreSQL. I used the EMS DataPump utility
(http://www.ems-hitech.com/index.phtml) to migrate the database, but
noticed that in the process it truncated a few large text blocks. I then
plugged the
Dino Nardini [EMAIL PROTECTED] writes:
Error while executing the query; Query string is too long
The entry fields are set to text datatype, so should easily handle
the web page content. I'm thinking that the problem may be related to
the driver. The content management system manages pages
45 matches
Mail list logo
