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". Everybody from E.F. Codd onward has struggled with the view updatability problem; it seems like PostgreSQL is one unnecessary constraint away from letting users find a pragmatic solution (a.k.a. workaround) for it. ~ Ken > -----Original Message----- > From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] > Sent: Sunday, February 12, 2006 6:43 PM > To: ken@xxxxxxxxxxx > Cc: 'PostgreSQL pg-general List' > Subject: Re: [GENERAL] Why does an ON SELECT rule have to be named > "_RETURN"? > > "Ken Winter" <ken@xxxxxxxxxxx> writes: > > * Why this constraint? > > * Would anything break if I were allowed to get away with my little > trick? > > * Is there any way to get around the constraint? > > The reason why the table is converted to a view is that ancient pg_dump > dumps used to create views in exactly that way (make a table and then > add an ON SELECT rule) and so when we started making a hard distinction > between tables and views, we needed to force the conversion to occur. > > The notion of a real table that has an ON SELECT rule seems fairly > broken to me in any case. I think you should be complaining to the > authors of your client-side tools that they won't do what you want. > It would probably be quite a trivial change to get them to support > data entry forms against views, but changing the backend on this > point won't be an easy sell. > > regards, tom lane
