I'm trying to build something that behaves like an updatable view but that PostgreSQL (version 7.4) regards and presents to the world as a table. The reason I want to do this odd thing is that my front-end tools (phpPgAdmin and PostgreSQL Lightning Admin) have handy pre-made data entry and viewing forms, but they only work against tables (not against views). The PostgreSQL documentation (http://www.postgresql.org/docs/7.4/static/rules-views.html) says that: "There is essentially no difference between CREATE VIEW myview AS SELECT * FROM mytab; compared against the two commands CREATE TABLE myview (same column list as mytab); CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD SELECT * FROM mytab; because this is exactly what the CREATE VIEW command does internally." OK, I figured, so if I turn my existing view (made updatable by suitable ON INSERT, ON UPDATE, and ON DELETE rules), which works fine, into a table with an ON SELECT rule on the above pattern, that ought to work. But I decided to name my ON SELECT rule something other than "_RETURN", so PostgreSQL wouldn't suspect what I was up to. Alas, PostgreSQL responded with an error message saying that a "view rule...must be named "_RETURN"'. When I renamed it thus, PostgreSQL accepted the whole thing - but ended up classifying the resulting structure as a view, which defeated my purpose of making it accessible through my front-end tools. So I'm wondering: * 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? ~ TIA ~ Ken
