From: | Chris Dunlop <chris(at)onthe(dot)net(dot)au> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Update using sub-select table in schema |
Date: | 2006-10-02 02:19:50 |
Message-ID: | 20061002021950.GA7792@onthe.net.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
G'day all,
PG version: 8.1.4 (also 7.4.13)
OS: Linux (debian/testing)
In an update, using a sub-select from a table with the same name
but in a different schema results in an error. The same thing
works if you alias the sub-select table or if you qualify the
schema of the update table.
See script below.
I'm not sure if this is a bug or if it's displaying my ignorance
of this corner of SQL...
Cheers,
Chris.
----------------------------------------------------------------------
create table a (id integer, name text);
insert into a values ('1', 'thomas');
insert into a values ('2', 'edward');
create schema temp;
create table temp.a (id integer, name text);
insert into temp.a values ('1', 'tom');
insert into temp.a values ('2', 'eddie');
--
-- fails with:
-- ERROR: more than one row returned by a subquery used as an expression
--
update a set name = (
select name
from temp.a
where temp.a.id = a.id
)
--
-- same thing with schema-qualified update table: works as expected
--
update public.a set name = (
select name
from temp.a
where temp.a.id = public.a.id
);
--
-- same thing but using an alias: works as expected
--
update a set name = (
select name
from temp.a foo
where foo.id = a.id
);
----------------------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-02 15:38:45 | Re: Update using sub-select table in schema |
Previous Message | Tom Lane | 2006-10-02 02:05:43 | Re: BUG #2667: vacuuming a 70GB table causes a "crash" |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-10-02 03:51:34 | Re: Select for update with outer join broken? |
Previous Message | ITAGAKI Takahiro | 2006-10-02 01:52:48 | Re: Another idea for dealing with cmin/cmax |