Re: Updateable Views?

Just wondering, is updateable views slated for a
future version of Postgresql? In addition to using
rules that is.

CSN

__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

CSN wrote:
>
> Just wondering, is updateable views slated for a
> future version of Postgresql? In addition to using
> rules that is.

Yes, I think some folks are working on it for the next release.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, 2004-08-03 at 13:05, CSN wrote:
> Just wondering, is updateable views slated for a
> future version of Postgresql? In addition to using
> rules that is.

It's on the todo list. Of course, the just means someone someday should
do it, but it's not on anybody's personal todo list that I know of.

I would think that a basic fleshing out of the logic with some kind of
stored proc to make the views and triggers would likely get someone
started on the backend work. You know, a proof of concept thingy.

"Scott Marlowe" <smarlowe(at)qwest(dot)net> writes:

> On Tue, 2004-08-03 at 13:05, CSN wrote:
> > Just wondering, is updateable views slated for a
> > future version of Postgresql? In addition to using
> > rules that is.
>
> I would think that a basic fleshing out of the logic with some kind of
> stored proc to make the views and triggers would likely get someone
> started on the backend work. You know, a proof of concept thingy.

I have some fears here. It seems everyone's first thought when they think
about updateable views is to think about constructing rules on the views.

How would that approach help with inline views? Things like:

UPDATE (SELECT a+b AS x, c AS y FROM foo) SET c=1 WHERE x = 10

It seems like starting with these types of views in the backend would be more
productive than implementing something in rules. Once postgres can handle
inline views it should be trivial to handle persistent views just like they're
handled on selects.

--
greg

--On Dienstag, August 03, 2004 20:51:45 -0600 Scott Marlowe
<smarlowe(at)qwest(dot)net> wrote:

> On Tue, 2004-08-03 at 13:05, CSN wrote:
>> Just wondering, is updateable views slated for a
>> future version of Postgresql? In addition to using
>> rules that is.
>
> It's on the todo list. Of course, the just means someone someday should
> do it, but it's not on anybody's personal todo list that I know of.
>

No, its on mine :)

> I would think that a basic fleshing out of the logic with some kind of
> stored proc to make the views and triggers would likely get someone
> started on the backend work. You know, a proof of concept thingy.
>

That's exactly what i'm working on. Currently I have a stored procedure
pg_create_view_updrule() that takes the OID of the view _RETURN rule and
forms
an INSERT rule from it (DELETE/UPDATE are not yet implemented). To get down
the query trees is a bit complex, but it seems to work right now, although
there's many i have to do in the next days.....i will post as soon as I
have a working proof-of-concept. Please note that i'm heading for
SQL92-compliance, SQL99 seems a todo for the next-generation.

Bernd

On Tuesday 03 August 2004 08:38 pm, Greg Stark wrote:
> "Scott Marlowe" <smarlowe(at)qwest(dot)net> writes:
> > On Tue, 2004-08-03 at 13:05, CSN wrote:
> > > Just wondering, is updateable views slated for a
> > > future version of Postgresql? In addition to using
> > > rules that is.
> >
> > I would think that a basic fleshing out of the logic with some kind of
> > stored proc to make the views and triggers would likely get someone
> > started on the backend work. You know, a proof of concept thingy.
>
> I have some fears here. It seems everyone's first thought when they think
> about updateable views is to think about constructing rules on the views.
>
> How would that approach help with inline views? Things like:
>
> UPDATE (SELECT a+b AS x, c AS y FROM foo) SET c=1 WHERE x = 10
>
> It seems like starting with these types of views in the backend would be
> more productive than implementing something in rules. Once postgres can
> handle inline views it should be trivial to handle persistent views just
> like they're handled on selects.

I think you are putting the cart before the horse. We have to get things
working and get the rules figured out before we can start modifying the
backend. Once we get it all figured out, implemented, tested, and debugged,
then maybe we can start considering modifying the backend.

--
Jonathan Gardner
jgardner(at)jonathangardner(dot)net

On 8/3/2004 11:38 PM, Greg Stark wrote:

> "Scott Marlowe" <smarlowe(at)qwest(dot)net> writes:
>
>> On Tue, 2004-08-03 at 13:05, CSN wrote:
>> > Just wondering, is updateable views slated for a
>> > future version of Postgresql? In addition to using
>> > rules that is.
>>
>> I would think that a basic fleshing out of the logic with some kind of
>> stored proc to make the views and triggers would likely get someone
>> started on the backend work. You know, a proof of concept thingy.
>
> I have some fears here. It seems everyone's first thought when they think
> about updateable views is to think about constructing rules on the views.
>
> How would that approach help with inline views? Things like:
>
> UPDATE (SELECT a+b AS x, c AS y FROM foo) SET c=1 WHERE x = 10

There is no such thing as an "inline view". What you show here is a
subselect, and I have not heard of "updatable subselects" yet. Could you
point me to the section in the ANSI SQL specifications that describes
this feature please?

Jan

>
> It seems like starting with these types of views in the backend would be more
> productive than implementing something in rules. Once postgres can handle
> inline views it should be trivial to handle persistent views just like they're
> handled on selects.
>

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

On Sat, 07 Aug 2004 10:24:34 -0400, Jan Wieck <JanWieck(at)Yahoo(dot)com>
wrote:
>I have not heard of "updatable subselects" yet.

http://asktom.oracle.com/pls/ask/f?p=4950:8:6693556430011788783::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:273215737113,

| Here we update a join. [...]
| scott(at)ORA734(dot)WORLD> update
| 2 ( select columnName, value
| 3 from name, lookup
| 4 where name.keyname = lookup.keyname
| 5 and lookup.otherColumn = :other_value )
| 6 set columnName = value
| 7 /

Google for
oracle "delete statement" syntax
or
oracle "update statement" syntax

Servus
Manfred