Re: numeric hierarchy again (was Re: floor function in 7.3b2) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: numeric hierarchy again (was Re: floor function in 7.3b2)
Date
Msg-id 25747.1033758460@sss.pgh.pa.us
Whole thread Raw
In response to Re: numeric hierarchy again (was Re: floor function in 7.3b2)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Threaded Sorting
Next
From: Greg Copeland
Date:
Subject: Re: Threaded Sorting