From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Clark Evans" <clark(dot)evans(at)manhattanproject(dot)com> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] libpq and SPI |
Date: | 1999-03-15 10:00:10 |
Message-ID: | 000f01be6eca$9c8eb580$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello all,
> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
> Sent: Monday, March 15, 1999 3:21 AM
> To: Clark Evans
> Cc: pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Bradetich | 1999-03-15 10:12:20 | Sequences.... |
Previous Message | Peter Mount | 1999-03-15 09:04:33 | RE: [HACKERS] ICQ? |