Re: [HACKERS] RULE (and ALTER TABLE) questions
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] RULE (and ALTER TABLE) questions |
Дата | |
Msg-id | 36C46055.50875098@trust.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [SQL] RULE questions. (jwieck@debis.com (Jan Wieck)) |
Ответы |
Re: [HACKERS] RULE (and ALTER TABLE) questions
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: