Re: [INTERFACES] problem with numeric
От | Thomas Lockhart |
---|---|
Тема | Re: [INTERFACES] problem with numeric |
Дата | |
Msg-id | 38983F7A.5A115B84@alumni.caltech.edu обсуждение исходный текст |
Ответ на | problem with numeric ("Ken J. Wright" <ken@ori-ind.com>) |
Список | pgsql-interfaces |
> : 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
В списке pgsql-interfaces по дате отправления: