On Sat, 17 Jul 2004, David Newall wrote:
> On Sat, 2004-07-17 at 13:34, Tom Lane wrote:
> > I suspect the real issue is that the implied join order is not the same.
>
> With respect, the real issue is that using the view takes 100 times
> longer than not using it.
>
> > The view-based query is rea
David Newall <[EMAIL PROTECTED]> writes:
> It's clearly an optimisation issue:
No, it's an outer-join-semantics issue.
> select * from a join b optimises differently to select * from a join
> (select * from b) as b
The above claim is provably false. Now, if you throw in some more
tables and spr
Nishad Prakash <[EMAIL PROTECTED]> writes:
> If step (3) is perfomed by the postgres superuser, then certain
> indices and foreign key constraints are not re-created and I see the
> error "must be owner of relation ".
That's a tad hard to believe: superusers always have ownership rights.
Could we
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 13 Jul 2004, Nicolas Bottarini wrote:
>> In postgreSQL 7.3.2 when I execute the following query
>>
>> select replace('test %400% result', 'result', 'ok');
>>
>> it returns "test % ok"
> I think this was fixed in the 7.4 branch.
It was fixed in
Stephan Szabo <[EMAIL PROTECTED]> writes:
> You also did an optimization, removing the subquery which PostgreSQL
> isn't.
I suspect the real issue is that the implied join order is not the same.
The view-based query is really
a LEFT JOIN (b LEFT JOIN c LEFT JOIN d LEFT JOIN e)
while the
I'm trying to create a new database whose schema is the same as one
that already exists. To my surprise, the following steps don't work:
1) pg_dump -s db1 > db1_schema
2) createdb db2
3) psql -f db1_schema db2
Both db1 and db2 are created by the user "Bob", who also owns all the
tables in db1.
Bruno Wolff III wrote:
> I see the following behaivor on 7.4.3 and 7.4 stable from about a
> week ago: bruno=> create table test ();
> CREATE TABLE
> bruno=> alter table test add constraint test2 check('\\' = '');
> ALTER TABLE
> bruno=> \d test
> Table "public.test"
> Column | Type | Modifier
On Fri, Jul 16, 2004 at 16:49:25 -0500,
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> I see the following behaivor on 7.4.3 and 7.4 stable from about a week ago:
> bruno=> create table test ();
> CREATE TABLE
> bruno=> alter table test add constraint test2 check('\\' = '');
> ALTER TABLE
> bruno=>
I see the following behaivor on 7.4.3 and 7.4 stable from about a week ago:
bruno=> create table test ();
CREATE TABLE
bruno=> alter table test add constraint test2 check('\\' = '');
ALTER TABLE
bruno=> \d test
Table "public.test"
Column | Type | Modifiers
+--+---
Check con
On Tue, 13 Jul 2004, Nicolas Bottarini wrote:
> In postgreSQL 7.3.2 when I execute the following query
>
> select replace('test %400% result', 'result', 'ok');
>
> it returns "test % ok"
I think this was fixed in the 7.4 branch.
---(end of broadcast)-
In postgreSQL 7.3.2 when I execute the following query
select replace('test %400% result', 'result', 'ok');
it returns “test % ok”
And If I Execute:
select replace('test %%400%% result', 'result', 'ok');
it returns the correct result: “test %400% ok”
If this is a known BUG pl
On Sat, 10 Jul 2004 [EMAIL PROTECTED] wrote:
> I know this has been discussed many times before but I'm not entirely
> satisfied with the answer, which I understand is "views are essentially
> macros". Despite that Postgres is producing the correct output, I hope
> you'll all agree that the perf
I get this error when I try to initialise the database. Downloaded
today from http://www.hagander.net/pgsql/win32snap/
C:\>initdb -V
initdb (PostgreSQL) 7.5devel
C:\>initdb -L "c:/progs/postgres/share"
fgets failure: No error
The program "postgres" was found by INITDB.EXE but was not the same
v
People,
Thanks for your help with my problem with NULL values. Also, particular
thanks for a hint on where to find a copy of SQL-92 standard, something
I didn't already have. It was annoying to discover that UNIQUE didn't
have what I felt was the "obvious" meaning, but it doesn't and PostgreSQL
I know this has been discussed many times before but I'm not entirely
satisfied with the answer, which I understand is "views are essentially
macros". Despite that Postgres is producing the correct output, I hope
you'll all agree that the performance issue is serious enough to call
this a "bug."
Tom Lane <[EMAIL PROTECTED]> wrote:
> I assume though that this is a made-up example and is not the case
> that's really troubling you. What is the actual problem you are looking
> at?
I was generating random test data and naively assumed that ()::integer
truncated its value, therefore I was gett
16 matches
Mail list logo
