Tom Lane wrote:
Nis Jorgensen <[EMAIL PROTECTED]> writes:
Try removing the DISTINCT ON from your view - that should make things
clearer to you. When t.approved is true, the row is joined to all rows
of the datum table satisfying the criteria. The sort order you specify
does not guarantee a uniq
Hello all,
I think I found a little but annoying bug in views when ordering is
involved. First, my version of Postgres:
PostgreSQL 8.1.3 on i386-portbld-freebsd6.1, compiled by GCC cc (GCC)
3.4.4 [FreeBSD] 20050518
Please try the following:
CREATE TABLE datum (
projekt_id INTEGER NOT NUL
Tom Lane wrote:
=?ISO-8859-1?Q?Sebastian_B=F6ck?= <[EMAIL PROTECTED]> writes:
I patched my 8.1 installation with the following changes:
http://www-new.commandprompt.com/projects/public/pgsql/changeset/23461
The error described above doesn't exist any more, but it's still
buggy.
Yup, you'
Tom Lane wrote:
=?ISO-8859-1?Q?Sebastian_B=F6ck?= <[EMAIL PROTECTED]> writes:
I get unpredictibale results selecting from a view depending on
index-usage.
It's not actually *using* the indexes, although presence of the indexes
does seem to be needed to trigger the bug:
regression=# explain
Jaime Casanova wrote:
On 11/14/05, Sebastian Böck <[EMAIL PROTECTED]> wrote:
Hello,
I get unpredictibale results selecting from a view depending on
index-usage.
Please see the attached script for details.
Is it a bug or some "weird feature"?
Any help appreciated to get pred
Scott Marlowe wrote:
On Mon, 2005-11-14 at 11:07, Sebastian Böck wrote:
Hello,
I get unpredictibale results selecting from a view depending on
index-usage.
PostgreSQL uses a cost based planner. So, it tends to not use the plan
you might expect, especially in "toy" test cases
Hello,
I get unpredictibale results selecting from a view depending on
index-usage.
Please see the attached script for details.
Is it a bug or some "weird feature"?
Any help appreciated to get predictibale results
Sebastian
CREATE TABLE test1 (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL
Oleg wrote:
Dear All,
is it possible to temporary deactivate a constraint in PostgreSQL?
There is a constraint that does not allow me to write some data (see
e-mail below). But after all datasets are written the constraint is
valid. So I was wondering wether it is possible to deactivate a
cons
Tom Lane wrote:
=?ISO-8859-1?Q?Sebastian_B=F6ck?= <[EMAIL PROTECTED]> writes:
why is the last definition of a view not working, although the
documentation says all three are equal?
The documentation says no such thing...
So I misinterpreted the following:
http://www.postgresql.org/docs/8.
Hello all,
why is the last definition of a view not working, although the
documentation says all three are equal?
Testcase:
CREATE SCHEMA one;
CREATE SCHEMA two;
CREATE TABLE one.one (
id SERIAL PRIMARY KEY
);
CREATE TABLE two.two (
id SERIAL PRIMARY KEY
);
CREATE TABLE joi
Dawid Kuroczko wrote:
Control question, I didn't check it, but would it be enough to change from:
UPDATE join1 SET text1 = NEW.text1 WHERE id = OLD.id;
to:
UPDATE join1 SET text1 = NEW.text1 WHERE id = OLD.id AND text1 <> NEW.text1?
... I may be wrong. :)
Yes, thats more elegant then my
Sorry, missed the SQL to test.
Sebastian
/* tables */
CREATE TABLE test (
id INTEGER PRIMARY KEY,
test TEXT NOT NULL
);
CREATE TABLE join1 (
id INTEGER PRIMARY KEY,
text1 TEXT NOT NULL
);
CREATE TABLE join2 (
id INTEGER PRIMARY KEY,
text2 TEXT NO
Martijn van Oosterhout wrote:
I'm sure I'm not the only one, but, what are you talking about? RULEs
are not really obvious so it would help if you could post an example of
what you mean...
Have a nice day,
Hi, I'm not really talking about rules.
I'm talking about updates on *real* tables, and
Hi all,
maybe it's a very silly question, but why does Postgres perform an
update on the table even if no data changes?
I recognized this recently doing a rewrite of my rules because they
took to long. I had many conditional rules I collapsed to one
unconditional rule, so that the views get
Oleg Bartunov wrote:
On Thu, 28 Apr 2005, [ISO-8859-1] Sebastian B?ck wrote:
Hello,
i wanted to define and GIST-index on a table with a timestamp-column
containing 'infinity' values, and it throws the following error:
ERROR: cannot subtract infinite timestamps
Is this a known limitation?
I don't
Hello,
i wanted to define and GIST-index on a table with a timestamp-column
containing 'infinity' values, and it throws the following error:
ERROR: cannot subtract infinite timestamps
Is this a known limitation?
How can i avoid or circumvent this?
Thanks in advance
Sebastian
--
Ron Mayer wrote:
Did anyone get multi-column GIST indexes working using both
the gist_btree and postgis modules?
Not quite stable yet.
It seems to work fine for me on small test cases (shown
at the bottom), but seems to crash my database for large
ones. Any advice is welcome - including pointers
Richard Huxton wrote:
Sebastian Böck wrote:
Richard Huxton wrote:
Sebastian Böck wrote:
Richard Huxton wrote:
Can you post the output from your "explain analyse" calls too? The
statistics aren't going to be the same on different machines.
Sure, here it is.
Thanks. (PS - remember
Richard Huxton wrote:
Sebastian Böck wrote:
Richard Huxton wrote:
Can you post the output from your "explain analyse" calls too? The
statistics aren't going to be the same on different machines.
Sure, here it is.
Thanks. (PS - remember to cc the list too).
[output of EXPLAIN A
Hello all,
i have a problem with index usage and joins.
Attached is some SQL demonstrating my problem;
Why is the index only used in the 2nd query?
Can anybody explain me how to avoid/fix this.
Thanks in advance
Sebastian
CREATE TABLE users (
login NAME NOT NULL PRIMARY KEY,
datum T
Tom Lane wrote:
=?ISO-8859-1?Q?Sebastian_B=F6ck?= <[EMAIL PROTECTED]> writes:
infinite recursion detected in rules for relation "..."
If you need a patch immediately, here it is.
*** src/backend/rewrite/rewriteHandler.c.orig Sat Nov 6 12:46:35 2004
--- src/backend/rewrite/rewriteHandler.c Sat Nov
Hello all,
i have a problem migrating my application from version
7.4 to 8.0. Everything is fine in 7.4 but with 8.0 i get
the following error:
infinite recursion detected in rules for relation "..."
I've been able to narrow the problem down to the
attached SQL.
I don't know wether its a bug or a "
Tom Lane wrote:
=?ISO-8859-1?Q?Sebastian_B=F6ck?= <[EMAIL PROTECTED]> writes:
I investigated a little bit further and can be more precisely
about the whole thing. This (wrong) behaviour only occurs, if
the view has an order by clause.
The bug is triggered by the combination of an inherited UPDATE
Tom Lane wrote:
=?ISO-8859-1?Q?Sebastian_B=F6ck?= <[EMAIL PROTECTED]> writes:
Is this a known limitation with views, rules and
inherited tables i haven't heard of? Or is it a bug?
When you haven't shown us any details, it's impossible to tell.
Let's see the actual table, view, and rule definitions
Hello all,
i have a view defined as a simple select of a table.
This table is inherited by a couple of others.
All entries belong to the child-tables.
I also have an unconditional update rule on the view.
If i do an update to the view, the update is rewritten
to update the father-table.
And now a s
Andreas wrote:
Seastian Böck wrote:
for primary keys there is a simple (and at least working for me)
solution as long as you can use the SERIAL type for your primary
key.
[...]
Now the id column gets merged and you should have the desired
behaviour.
If you want objects.id to get referenced by othe
26 matches
Mail list logo
