Thread: Views and rules section (link provided below)
On the page: http://borg.postgresql.org/docs/8.0/static/rules-views.html Is the text (very close to the top): --------- Views in PostgreSQL are implemented using the rule system. In fact, 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; ---------- I did this the second way (actually using 7.3.4, but the documentation is nearly identical), and as I'm still a little new to postgres, I created my table with foreign key restraints, which works, but causes problems if you want to drop the view. I searched for a workaround on google, and found the following bug report: http://archives.postgresql.org/pgsql-bugs/2003-09/msg00134.php which received this reply: http://archives.postgresql.org/pgsql-bugs/2003-09/msg00135.php If it's unsupported, okay, no big deal, I won't do that anymore, but the exact detail that Tom Lane's response says is unsupported is the same as the above example taken straight from the manual. I don't claim to know the best way to rewrite the section, but I'd like to put forward the suggestion that it not use any unsupported examples. Thank you for your consideration, -Rob __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Rob LoPresti <mooingyak@yahoo.com> writes:
> ... I don't claim to know the best way to rewrite the section, but I'd
> like to put forward the suggestion that it not use any unsupported
> examples.
The example *as written* works fine. Doing other stuff in between the
two steps (such as loading data into the table) isn't supported, but
pointing that out in the rules discussion seems like distracting
pedantism, rather than information that's helpful right at that point.
Can you think of another place it'd be worth mentioning?
regards, tom lane
Rob LoPresti <mooingyak@yahoo.com> writes: > > ... I don't claim to know the best way to rewrite the section, but I'd > > like to put forward the suggestion that it not use any unsupported > > examples. > The example *as written* works fine. Doing other stuff in between the > two steps (such as loading data into the table) isn't supported, but > pointing that out in the rules discussion seems like distracting > pedantism, rather than information that's helpful right at that point. I made my previous post because I originally had the mistaken assumption that adding foreign key restraints was actually a necessary step (in retrospect, with a better grasp of the concepts, that seems very silly). While the language is clearer in the 8.0 manual (same column list as mytab) than in the 7.3 manual (same attribute list as for mytab), I felt that it might benefit from a simple warning to the effect that *only* the columns, and nothing else (like indexes, triggers, etc) should be included. I can accept that this might be overly pedantic, but my goal here is to prevent someone else from making my mistake. I have not yet covered enough of the manual to suggest a different place where this warning might be appropriate, so I regretfully can't offer any ideas on that front. Thanks, -Rob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com