Обсуждение: Updatable view?
Hi, Is anyone working on implementing or interested in implementing automatic updatable view which uses two or more tables involved (join)? SQL1999 allows it in certain conditions. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 7/30/15 1:03 AM, Tatsuo Ishii wrote: > Is anyone working on implementing or interested in implementing > automatic updatable view which uses two or more tables involved > (join)? SQL1999 allows it in certain conditions. I think it would be nice to have... but not to the point of working on it myself. Might be worth an email to -general to see how many people have immediate use for it. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com
> I think it would be nice to have... but not to the point of working on > it myself. > > Might be worth an email to -general to see how many people have > immediate use for it. What I am thinking about is, 1) Implement certain class of updatable views allowed in SQL:1999 (UNION ALL, natural joins) 2) Anything beyond #1 (I have no idea for now) Let me see how people are interested in... Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
> On 31 Jul 2015 10:15, "Tatsuo Ishii" <ishii@postgresql.org> wrote: >> >> > I think it would be nice to have... but not to the point of working on >> > it myself. >> > >> > Might be worth an email to -general to see how many people have >> > immediate use for it. >> >> What I am thinking about is, >> >> 1) Implement certain class of updatable views allowed in SQL:1999 >> (UNION ALL, natural joins) >> >> 2) Anything beyond #1 (I have no idea for now) >> >> Let me see how people are interested in... >> > > How does the standard define it? Do they also follow the same MVCC > semantics as normal tables? In my understanding there's no such concept like MVCC in the standard. Anyway in our implementation, we should keep the MVCC semantics of course. > I am concerned that we may end up losing read > performance for views if we implement this (unless I am missing something) Why do updatable views lose read performance? I thought the only performance concern will be in the update/delete/insert operations. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
<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 />