| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
| Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Michael Meskes <meskes(at)postgreSQL(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8' |
| Date: | 2000-02-17 07:38:46 |
| Message-ID: | 14988.950773126@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> I proposed a while back that T_Float tokens ought to carry the value in
>> string form, rather than actually converting it to float,
> No fair only doing it for float8; int4 has the same trouble.
Au contraire: int representation has no risk of loss of precision.
It does risk overflow, but we can detect that reliably, and in fact
scan.l already takes care of that scenario.
If we allow ints to retain their current representation, then the
manipulations currently done in gram.y don't need to change. All
that's needed is to invoke the proper typinput function after we've
decided what type we really want to convert a T_Float to. T_Float
would act kind of like UNKNOWN-type string constants, except that
the knowledge that the string looks numeric-ish could be used in
type selection heuristics.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2000-02-17 09:30:20 | Re: [HACKERS] FYI: BNF for SQL93 and SQL-3 |
| Previous Message | Tom Lane | 2000-02-17 07:28:04 | Re: [HACKERS] Almost there on column aliases |