Re: [HACKERS] CVS Branch Tagging...
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] CVS Branch Tagging... |
Дата | |
Msg-id | 362ECC4D.D012E740@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] CVS Branch Tagging... (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] CVS Branch Tagging...
|
Список | pgsql-hackers |
> Thomas, can you check the pg_proc table, and remove any of the > functions that are no longer needed. Seems we have a lot of them in > there that used to do conversions, that are no longer needed. > There are even functions to convert from int2 to int2. We are also > running low on systgem oids. Is this a problem for v6.4? Perhaps we can go with what we have for now, and do a cleanup early in v6.5 development? One thing: I've been thinking that, although we now do "automatic coersions" of types which will try to do the right thing by converting expression or function arguments to the appropriate type if there is not direct match in the catalog, a direct match is always/usually better to have. So, for example, there is an operator defined to multiply an int2 by an int4. If one actually had an expression that was '2'::int2 * '4'::int4 then this operator would be used. If one removed this operator, then the expression would still be evaluated, but done as int4('2'::int2) * '4'::int4 which in this case will give the correct result, though be marginally slower because of the extra function call. But in principle there may be occasions when a "mixed type" operator will give a better/more accurate result than doing a type conversion and then a "uniform type" operation. So we should probably plan on leaving most of the mixed-type operators and functions in the system. - Tom
В списке pgsql-hackers по дате отправления: