On Thu, Nov 10, 2005 at 01:15:07PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > What I want to have is some builtin functions that can be used as the
> > input/output/cast/etc functions for each enum type.
>
> The hard part of that is going to be figuring out how to get the
> information to the functions about which enum type they're being invoked
> for. Output functions in particular are handed little except the data
> value itself.
For my taggedtypes module I simply created an output function for each
type, but they all referred to the same C function. The fmgr interface
does allow you to retreive your own OID, which allows you to search the
catalog to determine what type you were called with and/or need to
return. I actually built a little LRU cache for the
function-to-return-type lookup to avoid most of the overhead.
> Possibly the internal representation of an enum could be 8 bytes: 4
> bytes for type OID and 4 more for value. No doubt the mysql guys would
> rag on us for using too much disk space :-(. But if you did that then
> the generics would just be anyenum and done.
That's another way, but it is really worth the effort to make another any*
type. For arrays it's worth it because people assume you can make an
array of most things. But enums needs to be explicitly defined and how
many enums are you expecting anyway. Is pg_proc bloat an actual
concern?
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.