John Aughey <[EMAIL PROTECTED]> writes:
> However, this next one is slow.
> calendar=# explain select * from schedule where schedule.owner_id in
> (select group_id from groups where user_id=101);
IN is not very well implemented at present. You could try something
like this (in 7.1):
select sch
On Wed, 16 May 2001, Jonathan Ellis wrote:
> > > Would manually
> > > removing it from pg_trigger cause Bad Things to happen?
> >
> > Yes, and you'll need to double quote the trigger name.
> > try
> > drop trigger "RI_ConstraintTrigger_44349" on users;
>
> That worked. Why was that?
It's a mix
"Jeff Patterson" <[EMAIL PROTECTED]> writes:
> Strange date behavior as shown below.
This is not a date bug; it's your misunderstanding of how SQL functions
work. A function that returns a scalar can only return one result, so
it makes no sense to try to define its result as a SELECT from a
mul
> > Would manually
> > removing it from pg_trigger cause Bad Things to happen?
>
> Yes, and you'll need to double quote the trigger name.
> try
> drop trigger "RI_ConstraintTrigger_44349" on users;
That worked. Why was that?
> How did you drop the table? Did you reload a dump file (like the on
On Wed, 16 May 2001, Jonathan Ellis wrote:
> This is in 7.1.1:
>
> I was playing around with a table called user_comments and then dropped it.
> One of its columns referenced the user_id column of another table, users.
> Now whenever I try to update users, I get results like this:
> bf2-new=# up
This is in 7.1.1:
I was playing around with a table called user_comments and then dropped it.
One of its columns referenced the user_id column of another table, users.
Now whenever I try to update users, I get results like this:
bf2-new=# update users set last_visit=sysdate() where user_id=4; ERR
I'm stress testing my application by creating large data sets. This
particular query selects rows from the schedule table that have a specific
owner_id. (I'll show you the results of explain)
calendar=# explain select * from schedule where schedule.owner_id=101 or
schedule.owner_id=102;
Index S
POSTGRESQL BUG REPORT TEMPLATE
Your name : Alex Verstraeten
Your email address : [EMAIL PROTECTED]
System Configura
Peter Eisentraut writes:
>> I don't see much value in fixing this just for libreadline (and even
>> less in fixing it by disabling readline support entirely). I think I
>> recall Peter E. having mentioned that there'd be a better answer in
>> autoconf 2.50 ... so I'm inclined not to touch the pro
Title: date bug
Strange date behavior as shown below.
create table "holidays" ("date" date NOT NULL,"name" varchar(25));
insert into holidays values ('01-01-2001'::date,'New Years');
insert into holidays values ('01-15-2001'::date,'Kings Birthday');
insert into holidays values ('02-19-2
To Whom It May Concern:
Just wanted to share with you the errors I keep getting trying to upgrade my
current version 6.5 of Postgresql to 7.1.
1.) Installed 6.5 via the Red Hat linux install of 6.2
2.) Have plenty of hardware (dual 600's, 2Gig RAM, 18G HD).
3.) Downloaded 7.1 tar f
Hello,
I try the procedure explained
Techdocs.posgresql.org/installguide.php
No problem to configure and make
But : make install give me this
All of PostgreSQL successfully made. Ready to install.
[localhost:sources/PostGresql/postgresql-7.1.1] root# make install
make -C doc install
mkdir /usr
> However, EvalPlanQual still leaks more memory than suits me ---
> auxiliary memory allocated by the plan nodes is not recovered.
> I think the correct way to implement it would be to create a new
> memory context for each level of EvalPlanQual execution and use
> that context as the "per-query c
> > How subselects run queries again and again?
>
> They don't end and restart them; they just rescan them. If we had
Thanks for recollection.
> this substitute-a-new-tuple hack integrated into the Param mechanism,
> then EvalPlanQual could use ExecReScan too, but at the moment no...
I see.
On Wed, 16 May 2001 [EMAIL PROTECTED] wrote:
> Stephen Deasey ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> Foreign key constraints on inherited columns, 2 errors.
>
> Long Description
> Using the Postgres 7.1.1 RPMs
Jeff Liu ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
PostgreSQL 7.1+ screw up Chinese Encoding after JDBC
Long Description
I can read Chinese Encoding (gb2312) using select statement manually
in psql after I installed Postg
Jon Pastore ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Loss of avg() functionality
Long Description
In v7.0.3 we use avg() with a type money column and it works just fine. In the new
7.1 (which btw way to verify we did a
Stephen Deasey ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Foreign key constraints on inherited columns, 2 errors.
Long Description
Using the Postgres 7.1.1 RPMs I typed the following into psql:
=# create table foo (foo in
18 matches
Mail list logo
