Sender: lockhart@hub.org
Message-ID: <38983F7A.5A115B84@alumni.caltech.edu>
Date: Wed, 02 Feb 2000 14:30:18 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "Ken J. Wright" <ken@ori-ind.com>, pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] problem with numeric
References: <3.0.1.32.20000201095714.00b16440@ori-ind.com>
	<16963.949464917@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> : Why is NUMERIC not considered numeric by TypeCategory()?  Why is DATE not
> : considered a datetime type?  Isn't this routine fundamentally broken?
> : If we need a category it should be taken from a pg_type field, not
> : hardwired in code...
> Thomas, what say you?

Not sure why DATE is not a date/time type. NUMERIC is not included for
two reasons: it is newer than the other code, and I'm not certain
where it should appear in a "promotion heirarchy" due to its
performance.

But in general you are right. I did the implementation using hardcoded
info, with the expectation that the eventual "right answer" would
involve allowing the type equivalence *and* type promotion info to be
stored in a table. For one thing, that is the only way afaik to get
user-defined types to participate in this implicit type coersion
scheme.

But at the time I didn't want to take the leap to defining a new table
or adding a column(s) to pg_type, until the current scheme was in the
field for a while and others had a chance to exercise it and
contribute ideas. 

I was assuming that a new table would be required, rather than using
pg_type, but maybe we only need two columns in a one-to-one
relationship and if so then pg_type might suffice. Are new columns
"typecategory" and "promotiontype" sufficient??

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California