On Tue, 2005-11-08 at 19:30 -0800, Jonathan Ellis wrote: > I tried to use PG inheritance in a project earlier this year. It > quickly became clear that it's not very useful except for toys. Which > is unfortunate, because it has the potential to make life a lot easier > in some situations.
It's certainly not the main selling point of PostgreSQL, but it's very handy in the right situation (not all of them being toys). The fruit example was contrived to fit the request. There are other very useful ways to use it. One way works more like an "interface" then "inheritance." Let's say that you had an app that validated shipping addresses. You could make a table that defined what a shipping address is and then inherit from that table for your "accounts", "stores" and "taco shops" table. You now know that all of the new tables have the exact same underlying fields that you build your validating code against. And you can run the same code against each of the tables because they implement that interface. Because it allows for multiple inheritance of tables it can work like an "is a" or a "has a." Thats kinda cool if you ask me. And you didn't give anything up to try it. Another thing thats nice is you can SELECT from the base table and get all of the shipping address in one shot (no need to do what would otherwise be a messy bit of SQL). All of the complaints that you will hear about inheritance are concerning PKs. PG leaves PK with inheritance up to you. I don't see that as a weakness if it gives me flexibility. And none of the developers are tackling it because it's not a hot topic. I kinda look at it like updateable views. Just because the developers can't settle on a "best approach" it doesn't get advanced. Anyway, long winded opinion that will sway nobody. You should play around with them some more and see if you can't figure how to best make them work for you. Or, not. Regards, Gabe /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
