Re: Advices on custom data type and extension development

>
> 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.
>

+1

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
casual observer.