Re: Reducing the overhead of NUMERIC data

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reducing the overhead of NUMERIC data
Дата
Msg-id 10595.1130973157@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reducing the overhead of NUMERIC data  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Reducing the overhead of NUMERIC data  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: Reducing the overhead of NUMERIC data  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> It seems straightforward enough to put in an additional test, similar to
> the ones already there so that if its too big for a decimal we make it a
> float straight away - only a float can be that big in that case. After
> that I can't really see what the problem is?

Wrong answer.  You'll be introducing weird corner cases into the type
resolution behavior.

An approach that would actually have some credibility would be to not
resolve constants to NUMERIC right away, but to invent an UNKNOWNNUMERIC
pseudotype with coercion behavior comparable to the existing UNKNOWN
type for string literals.  This has been proposed before but hasn't
really been needed so far.  Of course, this converts the project from a
minor localized hack on NUMERIC into a major piece of fiddling with the
type resolution rules, with the potential for unforeseen side-effects on
the behavior of other data types.  It might be worth doing anyway --- I
don't recall at the moment what problems UNKNOWNNUMERIC was intended to
solve, but if they're still open issues then it's something we ought to
get around to sometime.

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Reducing the overhead of NUMERIC data
Следующее
От: Robert Creager
Дата:
Сообщение: Re: Assert failure found in 8.1RC1