Re: Storage sizes for dates/times (documentation bug?)

On Tue, Apr 15, 2008 at 04:23:42PM +0200, Karsten Hilbert wrote:
>     When you delete a tagged type some cruft is left behind
>     (not in the system catalog though).
>
> Perhaps I confuse this with some limitation of a previous
> implementation of the enum type. Also perhaps I was
> misguided into thinking tags cannot be modified by the
> "don't delete from table of tags" part.

Oh, it means that if you DROP the type it will leave some stuff behind.
You can ofcourse handle *value* of that type just like any other value.
The 'tag table' in this case would be the list of timezones. I'll see
if I can clarify it.

> > Truly, taggedtypes are a really useful feature but I think the chance
> > of them being in the main tree approximatly nil, which is enough reason
> > to stay away from them.
> Agree. Another one is non-indexability which I'd truly need.

Well, you can index them ofcourse, but you need to indicate explicitly
what you want to index: the timestamp or the timestamp shifted to the
timezone. I felt the module couldn't make this decision on its own.
Indexing the type directly would be more work, not sure if there's
enough demand for it.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.