Re: [HACKERS] Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly |
Дата | |
Msg-id | 35227493.75D281E@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
> > So at least 5 different places, perhaps more when you get into it :( > OK, let's take a look at it. The only one I have seen a problem with > is: > > | '-' a_expr %prec UMINUS > > But let's look at the others. Default_expr has it: > > default_expr: AexprConst > { $$ = makeConstantList((A_Const *) $1); } > | NULL_P > { $$ = lcons( makeString("NULL"), NIL); } > | '-' default_expr %prec UMINUS > { $$ = lcons( makeString( "-"), $2); } > > But I don't understand why it is there. Doesn't AexprConst handle > such a case, or do we get shift-reduce conflicts without it? No, _no_ negative numbers get through scan.l without being separated into a minus sign and a positive number. This is because the scanner does not have any information about context, and cannot distinguish the usage of the minus, for example between the two cases "a - b" and "- b". So, to handle "a - b" correctly, the minus sign must always be separated, otherwise you get "a (-b)" which the grammar does not understand. The one place which will see every node come through is in the parser transformations or in the optimizer, which is why it seems that those might be good places to look for this case. - Tom
В списке pgsql-hackers по дате отправления: