Jan Wieck wrote:
>
> > These could probably be implemened more effectively using rules. Having
> > the
> > rules generated automatically for simple cases would of course be nice,
> > but a warning at least should be given to user about creating the rule,
> > like it's currently done with primary key.
>
> No it can't.
>
> Such a rule would look like
>
> CREATE RULE xxx AS ON INSERT TO this_table
> DO INSTEAD INSERT INTO this_table ...
>
> The rule system will be triggerd on an INSERT INTO
> this_table, rewrite and generate another parsetree that is an
> INSERT INTO this_table, which is recursively rewritten again
> applying rule xxx...
>
> That's an endless recursion. A rule can never do the same
> operation to a table it is fired for.
But when doing that at the table creation time, then the table can
actually
be defined as a view on storage table and rules for insert update and
delete
be defined for this view that do the actual data manipulation on the
storage table.
Or is the rule system currently not capable for this ?
When some field is changed to UPPER-ONLY status using alter table, the
table
could be renamed to staorage table and all the rules be created ?
And the other question - what is the status of ALTER TABLE commands -
can we add/remove/disable constraints without recreating the table ?
Is constraint and index disabling supported at all ?
-------------------
Hannu