Re: Rules: A Modest Proposal - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Rules: A Modest Proposal
Date
Msg-id 408cad003945d9a8837dccd6c77bc3fd@biglumber.com
Whole thread Raw
In response to Rules: A Modest Proposal  (David Fetter <david@fetter.org>)
Responses Re: Rules: A Modest Proposal
Re: Rules: A Modest Proposal
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----                              
Hash: RIPEMD160                                                 

> At the moment, user-accessible RULEs have, as far as I know, 
> just two sane uses:                                          
>                                                              
> * Writing to VIEWs                                           
> * Routing writes to partitions                               

Maybe you need a larger clientele list, because I still run up against 
RULEs in production environments that don't fit into the categories    
above. Here's one I came across just a couple weeks ago. Names changed 
for privacy:                                                           

CREATE RULE update_other_table
AS ON INSERT TO myschema.mytable
DO ALSO
INSERT INTO myschema.othertable (col1,col2,col3)
VALUES (NEW.col1, NEW.col2, NEW.col3);

Could this be done with a trigger? Yes, but on the plus rules side:

* It's faster
* It's easier to write
* It's immediately viewable as to what is going on with a \d mytable
* Dropping it won't leave an unused function around
* We can still do ALTER TABLE DISABLE TRIGGER ALL

I can give more examples, if you like, but removing a major feature of
Postgres with no real justificatgion seems a bit hasty, to say the least.

> They're mostly a foot-gun.

Lots of things in Postgres could be considered potential foot guns. Frankly,
I don't think rules are even near the top of such a list. Can you give
examples of rule foot guns?

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200910050758
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkrJ5wUACgkQvJuQZxSWSsjS7ACeMl8YfE38aVjnhZX3/gp8Ffgq
tZsAoLQPaPxS5ky4SZ8yXMdKNTWN1ZVX
=RmyV
-----END PGP SIGNATURE-----




pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: Review of "SQLDA support for ECPG"
Next
From: Bruce Momjian
Date:
Subject: Re: Rules: A Modest Proposal