On Wed, 2006-11-15 at 16:38 -0500, Andrew Dunstan wrote: > My little enumkit tool allows you to create enumerations today very > easily, but its values are completely hardcoded. However, the above > trick still works. The downside is that each enumeration type requires a > tiny bit of compilation.
Andrew, Your enum sounds good, apart from the hardcoded/compilation thing. That is a data management nightmare AFAICS and so restricts the usefulness of the solution. It would be much better to read things dynamically into an array, so using an init function in *preload_libraries would work well. I'd also love any suggestions as to how we might be able to use a similar local-data-cacheing mechanism to work when we specify SQL standard FOREIGN KEYs. It would be really cool to say USING LOCAL CACHE or some way of avoiding the overhead of all those stored after triggers and SPI SELECT statements when we've got checks against tables with only a few rows where the values hardly ever change. The enum concept departs radically from the declarative Referential Integrity concepts that many of us are already used to. I'd like to be able to speed things up without radical re-design of the database... so a few nicely sprinked ALTER TABLE statements would be a much better way of implementing this IMHO. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
