Re: Allow round() function to accept float and double precision

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Allow round() function to accept float and double precision
Дата
Msg-id 1480693.1669859138@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Allow round() function to accept float and double precision  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Allow round() function to accept float and double precision  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> We do have some weirdness in some existing overloaded functions.
> pg_size_pretty() is an example.

> If you run: SELECT pg_size_pretty(1000); you get:
> ERROR:  function pg_size_pretty(integer) is not unique

Yeah, you have to be careful about that when proposing to overload
a function name.

> That occurs because we don't know if we should promote the INT into a
> BIGINT or into a NUMERIC. We have a pg_size_pretty() function for each
> of those.  I don't think the same polymorphic type resolution problem
> exists for REAL, FLOAT8 and NUMERIC.

I would counsel against bothering with a REAL version.  FLOAT8 will
cover that case just fine.

> I'm unsure what the repercussions of the fact that REAL and FLOAT8 are
> not represented as decimals.

The main thing is that I think the output will still have to be
NUMERIC, or you're going to get complaints about "inaccurate"
results.  Before we got around to inventing infinities for NUMERIC,
that choice would have been problematic, but now I think it's OK.

            regards, tom lane



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Allow round() function to accept float and double precision
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump