elein wrote:
> On Mon, Oct 10, 2005 at 07:18:01PM -0500, Jim C. Nasby wrote:
>> On Mon, Oct 10, 2005 at 05:05:46PM -0700, elein wrote:
>>> On Mon, Oct 10, 2005 at 05:42:31PM -0300, Marc G. Fournier wrote:
>>>> On Mon, 10 Oct 2005, David Fetter wrote:
>>>>
>>>>> In this case, it might be easier to make a writeable VIEW with two
>>>>> tables underneath and an appropriate call to ARRAY() and maybe to
>>>>> array_to_string()
>>>> Is there any work being done on UPDATEABLE VIEWs? I found, at one point,
>>>> a 'work around' for it, but just wondering if there is any work being done
>>>> on a more 'native' method ...
>>> We have updateable views if you write the rules for them.
>>> A default updateable view could only be accurate all the
>>> time if it only contained a single table reference. Our
>> Well, you can create multi-table views that are also updateable. IIRC
>> the restriction is that joins must all be inner joins and you can't be
>> doing any kind of group by. I know the DB2 docs talk about this and I'm
>> pretty sure Oracle's do as well.
>
> You can start adding the "yeah, buts" which only makes it more
> confusing. That is why I said "accurate ALL the time".
You can decide from a view's definition (and those of the tables /
functions it uses) whether it will be one of:
1. Updatable unambiguously (single table, some inner-join)
2. Updatable given some additional rules (most non-aggregate)
3. Not updatable (any aggregate view)
The main issue is "for the view row I want to update/insert, can I
identify the relevant key(s) for the underlying table(s)".
--
Richard Huxton
Archonet Ltd