From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:14:26 |
Message-ID: | 38AB9FD2.92869E92@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I proposed a while back that T_Float tokens ought to carry the value in
> string form, rather than actually converting it to float, so that we
> behave consistently while taking no precision risks until the target
> type is known for certain. Thomas seems not to want to do it that way,
> for some reason.
Hmm. We should then carry *all* numeric types as strings farther into
the backend, probably deeper than gram.y? Some of the input validation
happens as early as gram.y now, so I guess we would need to do some
conversion at that point for some contexts, and leave the numeric
stuff as a string in other contexts. No fair only doing it for float8;
int4 has the same trouble.
Just seems like a can of worms, but it is definitely (?) the right
solution since at the moment the early interpretation of numerics can
lead to loss of info or precision deeper in the code.
This could be a minor-release kind of improvement...
- Thomas
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-17 07:25:13 | Definitional issue for INET types |
Previous Message | Tom Lane | 2000-02-17 07:01:21 | Re: [HACKERS] libpq |