Re: [HACKERS] Status report: long-query-string changes
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Status report: long-query-string changes |
Дата | |
Msg-id | 37DC7358.AE1E6DAB@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Status report: long-query-string changes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Thomas Lockhart should speak up... > He knows he'll never have to answer for any of his theories actually > being put to test. If they were, they would be contaminated by reality. You talkin' to me?? ;) So, while you are on the lexer warpath, I'd be really happy if someone would fix the following behavior: (I'm doing this from memory, but afaik it is close to correct) For non-psql applications, such as tcl or ecpg, which do not do any pre-processing on input tokens, a trailing un-terminated string will be lost, and no error will be detected. For example, select * from t1 'abc sent directly to the server will not fail as it should with that garbage at the end. The lexer is in a non-standard mode after all tokens are processed, and the accumulated string "abc" is left in a buffer and not sent to yacc/bison. I think you can see this behavior just by looking at the lexer code. A simple fix would be to check the current size after lexing of that accumulated string buffer, and if it is non-zero then elog(ERROR) a complaint. Perhaps a more general fix would be to ensure that you are never in an exclusive state after all tokens are processed, but I'm not sure how to do that. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: