Skip site navigation (1) Skip section navigation (2)

Re: Proof of concept: auto updatable views

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proof of concept: auto updatable views
Date: 2012-07-01 23:54:58
Message-ID: 4FF0E352.8010400@darrenduncan.net (view raw or flat)
Thread:
Lists: pgsql-hackers
My thoughts on this is that it would be a very valuable feature to have, and 
would make Postgres views behave more like they always were intended to behave, 
which is indistinguishible to users from tables in behavior where all possible, 
and that the reverse mapping would be automatic with the DBMS being given only 
the view-defining SELECT, where possible. -- Darren Duncan

Dean Rasheed wrote:
> I've been playing around with the idea of supporting automatically
> updatable views, and I have a working proof of concept. I've taken a
> different approach than the previous attempts to implement this
> feature (e.g., http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php),
> instead doing all the work in the rewriter, substituting the view for
> its base relation rather than attempting to auto-generate any rules or
> triggers.
> 
> Basically what it does is this: in the first stage of query rewriting,
> just after any non-SELECT rules are applied, the new code kicks in -
> if the target relation is a view, and there were no unqualified
> INSTEAD rules, and there are no INSTEAD OF triggers, it tests if the
> view is simply updatable. If so, the target view is replaced by its
> base relation and columns are re-mapped. Then the remainder of the
> rewriting process continues, recursively handling any further
> non-SELECT rules or additional simply updatable views. This handles
> the case of views on top of views, with or without rules and/or
> triggers.
> 
<snip>
> 
> Obviously there's still more work to do but the early signs seem to be
> encouraging.
> 
> Thoughts?


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-02 04:04:37
Subject: Re: XX000: enum value 117721 not found in cache for enum enumcrash
Previous:From: Jeff JanesDate: 2012-07-01 23:07:02
Subject: Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group