Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
can create or modify rules for the table. Do setRuleCheckAsUser() while
loading rules into the relcache, rather than when defining a rule. This
ensures that permission checks for tables referenced in a rule are done with
respect to the current owner of the rule's table, whereas formerly ALTER TABLE
OWNER would fail to update the permission checking for associated rules.
Removal of separate RULE privilege is needed to prevent various scenarios
in which a grantee of RULE privilege could effectively have any privilege
of the table owner. For backwards compatibility, GRANT/REVOKE RULE is still
accepted, but it doesn't do anything. Per discussion here:
http://archives.postgresql.org/pgsql-hackers/2006-04/msg01138.php
RETURNING play nice with views/rules. To wit, have the rule rewriter
rewrite any RETURNING clause found in a rule to produce what the rule's
triggering query asked for in its RETURNING clause, in particular drop
the RETURNING clause if no RETURNING in the triggering query. This
leaves the responsibility for knowing how to produce the view's output
columns on the rule author, without requiring any fundamental changes
in rule semantics such as adding new rule event types would do. The
initial implementation constrains things to ensure that there is
exactly one, unconditionally invoked RETURNING clause among the rules
for an event --- later we might be able to relax that, but for a post
feature freeze fix it seems better to minimize how much invention we do.
Per gripe from Jaime Casanova.
(tgrelid, tgname). This provides an additional check on trigger name
uniqueness per-table (which was already enforced by the code anyway).
With this change, RelationBuildTriggers will read the triggers in
order by tgname, since it's scanning using this index. Since a
predictable trigger ordering has been requested for some time, document
this behavior as a feature. Also document that rules fire in name
order, since yesterday's changes to pg_rewrite indexing cause that too.
CREATE RULE bad_rule_combination_1 AS
ON SELECT TO emp
DO INSTEAD
SELECT * FROM toyemp;
CREATE RULE bad_rule_combination_2 AS
ON SELECT TO toyemp
DO INSTEAD
SELECT * FROM emp;
Tatsuo Ishii
occur unconditionally, even if the rule should otherwise execute
conditionally. This is more useful than giving an error, even though it's
not truly the correct behavior. Per today's pghackers discussion.
in cases of qualified rules as well as unqualified ones. Tweak rules
test to avoid cluttering output with dummy SELECT results. Update
documentation to match code.
the first paragraph:
As an example, say we wish to find all the records that
are in the temperature range of other records. In
effect, we need to compare the temp_lo and temp_hi
attributes of each EMP instance to the temp_lo and
temp_hi attributes of all other EMP instances.
I believe that EMP should read WEATHER, as the example query that
follows joins WEATHER to itself.
EMP is often used in Oracle examples.
Regards,
Graham
Other RULE cleanups
No big deal; fixed lots of other markup at the same time.
Bigest change: make sure there is no whitespace
in front of <term> contents.
This will probably help the other output types too.
Bruce Momjian
Tom Lane
Neil Conway
PostgreSQL Daemon
Peter Eisentraut
Thomas G. Lockhart
Tatsuo Ishii