From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Jaime Casanova <systemguards(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Thoughts about updateable views |
Date: | 2004-12-22 16:49:58 |
Message-ID: | DEFE7A13B0BC352715EA9170@sparkey.oopsware.intra |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--On Mittwoch, Dezember 22, 2004 11:25:42 -0500 Tom Lane
<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Huxton <dev(at)archonet(dot)com> writes:
>> There are two things (AFAICT) you need to be able to do to update (NOTE
>> - not insert) a view.
>> 1. Identify the underlying table(s) for the updated column(s)
>> 2. Identify (primary) key values for the table(s) being updated.
>> So - I could have a join listing users and how many email aliases they
>> have (so sum()) and still update their name, so long as the key for the
>> users table was present in the view.
>
> No; you'd also have to have some guarantee that a given underlying table
> row gives rise to at most one join row. If the same table row gives
> rise to multiple join rows, then a request specifying an UPDATE of just
> one of those join rows can't be satisfied.
>
Not sure if i understand correctly, but that means JOINs between 1:n
relations
falls under the "not updateable" category, because the "parent row"
triggers updates to n possible "child" rows?
--
Bernd
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-22 16:54:56 | Re: Thoughts about updateable views |
Previous Message | Tom Lane | 2004-12-22 16:34:50 | Re: oldish libpq bug still in RC2 |