Re: numeric hierarchy again (was Re: floor function in 7.3b2)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: numeric hierarchy again (was Re: floor function in 7.3b2) |
| Дата | |
| Msg-id | 25747.1033758460@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: numeric hierarchy again (was Re: floor function in 7.3b2) (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, I realize it is during parsing. I was just wondering if making
> constants coming in from the parser NUMERIC is a performance hit?
Offhand I don't see a reason to think that coercing to NUMERIC (and then
something else) is slower than coercing to FLOAT (and then something else).
Yeah, you would come out a little behind when the final destination type
is FLOAT, but on the other hand you win a little when it's NUMERIC.
I see no reason to think this isn't a wash overall.
> I see
> in gram.y that FCONST comes in as a Float so I don't even see were we
> make it NUMERIC.
It's make_const in parse_node.c that has the first contact with the
grammar's output. Up to that point the value's just a string, really.
The grammar does *not* coerce it to float8.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера