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
