<p dir="ltr"><br /> On 31 Jul 2015 11:59, "Tatsuo Ishii" <<a
href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>>wrote:<br /> ><br /> > > On 31 Jul 2015 10:15,
"TatsuoIshii" <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>> wrote:<br /> > >><br />
>>> > I think it would be nice to have... but not to the point of working on<br /> > >> > it
myself.<br/> > >> ><br /> > >> > Might be worth an email to -general to see how many people
have<br/> > >> > immediate use for it.<br /> > >><br /> > >> What I am thinking about
is,<br/> > >><br /> > >> 1) Implement certain class of updatable views allowed in SQL:1999<br /> >
>> (UNION ALL, natural joins)<br /> > >><br /> > >> 2) Anything beyond #1 (I have no idea for
now)<br/> > >><br /> > >> Let me see how people are interested in...<br /> > >><br /> >
><br/> > > How does the standard define it? Do they also follow the same MVCC<br /> > > semantics as
normaltables?<br /> ><br /> > In my understanding there's no such concept like MVCC in the standard.<br /> >
Anywayin our implementation, we should keep the MVCC semantics of<br /> > course.<br /> ><p dir="ltr">Yes I meant
ourinternal MVCC semantics. I will have to look at the way MVCC handles views for exact logic though<p dir="ltr">>
>I am concerned that we may end up losing read<br /> > > performance for views if we implement this (unless I
ammissing something)<br /> ><br /> > Why do updatable views lose read performance? I thought the only<br /> >
performanceconcern will be in the update/delete/insert operations.<p dir="ltr">I meant update, sorry. Pre coffee mails
tendto be incorrect :)<br />