Peter Eisentraut <peter_e@gmx.net> writes:
> On 2000-02-21, Tom Lane mentioned:
>> I've been ranting about this in a recent pghackers thread ;-).
>> The lexer shouldn't have to commit to a conversion to float8
>> in order to report that a token looks like a numeric literal.
> Has the ranting resulted in any idea yet? ISTM that keeping a non-integer
> number as a string all the way to the executor shouldn't hurt too much.
Well, actually it's sufficient to keep it as a string until the type
analyzer has figured out what data type it's supposed to be; then you
can feed it to that type's typinput conversion routine. After that
it's not the parser's problem anymore ;-).
I committed changes to do exactly that this morning. Thomas had been
saying that integer literals should be kept as strings too, but I don't
believe that and didn't do it.
> peter=> select 'a' like 'a';
> ERROR: Unable to identify an operator '~~' for types 'unknown' and 'unknown'
> You will have to retype this query using an explicit cast
> Is there a good reason that a character literal is unknown? I'm sure the
> reasons lie somewhere in the extensible type system, but if I wanted it to
> be something else explicitly then I would have written DATE 'yesterday'.
Remember that constants of random types like "line segment" have to
start out as character literals (unless you want to try to pass them
through the lexer and parser undamaged without quotes). So untyped
character literal has to be a pretty generic thing. It might be a good
idea for the type analyzer to try again with the assumption that the
literal is supposed to be type text, if it fails to find an
interpretation without that assumption --- but I think this is a
ticklish change that could have unwanted consequences. It'd need
some close examination.
regards, tom lane