Re: Feedback from LinuxWorld, London
От | Richard Huxton |
---|---|
Тема | Re: Feedback from LinuxWorld, London |
Дата | |
Msg-id | 434BAFA6.9020002@archonet.com обсуждение исходный текст |
Ответ на | Re: Feedback from LinuxWorld, London (elein <elein@varlena.com>) |
Список | pgsql-advocacy |
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
В списке pgsql-advocacy по дате отправления: