From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Ken Winter <ken(at)sunward(dot)org> |
Cc: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 'PostgreSQL pg-general List' <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why does an ON SELECT rule have to be named "_RETURN"? |
Date: | 2006-02-13 01:46:38 |
Message-ID: | 20060212173538.I855@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, 12 Feb 2006, Ken Winter wrote:
> Hi Tom ~
>
> You're right: I appealed to the PostgreSQL folks rather than the client
> tool builders. I did so because my guess is that the latter have a harder
> row to hoe: They have to figure out whether a view really IS updatable -
> most presumably aren't, so if they provide forms that offer to update views,
> most of the time these forms are going to crash. It seems harder for the
> client tool builders to figure out the updatability question than for
> PostgreSQL to let people (like me) do the "real table with ON SELECT" trick
> and take responsibility for making it work. I don't see why that is
> inherently "broken".
What does a "real table with ON SELECT" mean? For example, if a row is
"inserted" that doesn't come into the on select output, was a row
inserted? Can it cause unique key violations, can it satisfy a foreign key
constraint?
From | Date | Subject | |
---|---|---|---|
Next Message | Tham Shiming | 2006-02-13 01:50:08 | Re: Dropping a database that does not exist |
Previous Message | Craig White | 2006-02-13 01:29:36 | dumb question |