Re: [HACKERS] CVS Branch Tagging...
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] CVS Branch Tagging... |
Дата | |
Msg-id | 199810221308.JAA15272@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] CVS Branch Tagging... ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | 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. Yes. Leave it for 6.4. Just keep it mind next time you are looking in there. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: