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