"Tom Lane" <[EMAIL PROTECTED]> writes: > So this can fairly obviously be replaced by two new pg_type columns, > say "typcategory" and "typpreferred", where the latter is a bool. > Since the list of categories is pretty short and there's no obvious > reason to extend it a lot, I propose that we just represent typcategory > as a "char", using a mapping along the lines of > > BITSTRING_TYPE b > BOOLEAN_TYPE B > DATETIME_TYPE D > GENERIC_TYPE P (think "pseudotype") > GEOMETRIC_TYPE G > INVALID_TYPE \0 (not allowed in catalog anyway) > NETWORK_TYPE n ...
I had a different thought when you posted the original prompt earlier. Instead of a static list of type categories we could re-use type oids. So if you belong to a type category you store the oid of the preferred type of that category in typcategory. I can't help thinking from the list above that there's nothing special about datetime, geometric, and network data types that some user defined set of types wouldn't necessarily want to define. I do agree that having SQL commands to create new type categories, even a new catalog table is overkill, but not because we wouldn't want to create new ones. Just because there isn't really any other meta data we want to store about type categories. Aside from the preferred type and the members there isn't anything more to say about them. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
