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 по дате отправления:

Предыдущее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: [INTERFACES] New docs and ODBC for Unix
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] CVS Branch Tagging...