> Seriously, you should consider having a primary key with two
> columns, of type date and int. It would take exactly the same
> space as your current plan, and performance should be very close to
> what you propose. As long as you aren't using some ORM that is too
> dumb to deal with this, it should be far easier than creating the
> custom type.
Most ORMs cannot handle ENUMs, let alone user defined composite types.
That, or they *flood* the database with SELECT * FROM pg_type WHERE ...
queries. I'm looking at you, Cake.
You're far better off trying a (date,integer) key as Kevin said.
If the ORM doesn't allow that, I'd suggest a custom function that encodes
the date bit-shifted to the high 4 bytes, and then adds in the four bytes
from a cycling sequence. At least then you've got a shot at partitioning,
though the lower/upper bounds of the partitions would not make sense to the