Updatable view?

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 31 Jul 2015 11:59, "Tatsuo Ishii" <ishii@postgresql.org> wrote:

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.

Yes I meant our internal MVCC semantics. I will have to look at the way
MVCC handles views for exact logic though

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.

I meant update, sorry. Pre coffee mails tend to be incorrect :)