Re: [HACKERS] libpq and SPI
От
Tom Lane
Тема
Re: [HACKERS] libpq and SPI
Дата
Msg-id
29785.921435659@sss.pgh.pa.us
Ответ на
Re: [HACKERS] libpq and SPI (Clark Evans)
Список
Дерево обсуждения
Re: [HACKERS] libpq and SPI Clark Evans <clark.evans@manhattanproject.com>
Re: [HACKERS] libpq and SPI Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] libpq and SPI Tom Lane <tgl@sss.pgh.pa.us>
RE: [HACKERS] libpq and SPI "Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [HACKERS] libpq and SPI "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: [HACKERS] libpq and SPI Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] libpq and SPI Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] libpq and SPI jwieck@debis.com (Jan Wieck)
developers globe Bruce Momjian <maillist@candle.pha.pa.us>
Re: developers globe jwieck@debis.com (Jan Wieck)
> What is the problem? I'll research a SPI patch. Check the hackers thread (last month I think) titled "libpq and SPI"; the problem occurs when one submits a utility statement rather than a plannable query via SPI. Apparently what is happening is that the backend emits a 'T' message before it invokes the called statement and then emits a 'D' message afterwards --- so if the called statement causes a 'C' message to come out, libpq gets unhappy. This seems to be clearly a violation of the FE/BE protocol to me, so I don't think it's libpq's fault. Reasonable fixes might be to postpone the sending of 'T' till after the invoked statement is executed, or to modify the traffic cop so that a utility statement invoked from SPI doesn't send 'C'. I know a little bit about the parts of the backend that communicate with the frontend, but nothing about SPI, so I'm not well prepared to solve the problem by myself. regards, tom lane
В списке pgsql-hackers по дате отправления