RE: [HACKERS] libpq and SPI
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] libpq and SPI |
Дата | |
Msg-id | 000f01be6eca$9c8eb580$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] libpq and SPI (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: [HACKERS] libpq and SPI
|
Список | pgsql-hackers |
Hello all, > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane > Sent: Monday, March 15, 1999 3:21 AM > To: Clark Evans > Cc: pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] libpq and SPI > > > > 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. > Probably it's not the problem of SPI. Specific utility commands(CREATE USER/ALTER USER/DROP USER /CREATE DATABASE/DROP DATABASE) break FE/BE protocol when they are executed inside the PostgreSQL function call. They call pg_exec_query() (tcop/postgres.c) in their implementation. In many cases the destination of pg_exec_query() is "Remote" which means that results are sent to frontend process. But the results shouldn't be sent to the frontend directly inside the execution of PostgreSQL function. ProcessUtility() (tcop/utility.c) function processes utility commands and takes the destination of command results as its second parameter. So should we call pg_exec_query_dest(query_string, the destination parameter of ProcessUtility(), FALSE) instead of pg_exec_query(), shouldn't we ? Thanks. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: