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 по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] Status report: long-query-string changes
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] Fixing Simms' vacuum problems