Re: [HACKERS] Numeric with '-'
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Numeric with '-' |
Дата | |
Msg-id | 22122.951192349@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Numeric with '-' (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] Numeric with '-'
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: