-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 03 August 2004 12:12 pm, Jonathan Gardner wrote:
> I'll look into how to actually implement this at home tonight.
Well, it's two nights later but I think I made some headway. I discovered
the joy that is backend/tcop/postgres.c. I discovered that's were all the
messages are dispatched.
The two messages that Tom and others have been talking about are 'P' and
'D'.
'P' will prepare a statement. FE supplies the statement name (null is ok,
it seems), the query, and the number of params and the param Oids. Well,
except if you look at parse_analyze_varparams it seems that it *ignores*
the numParams and paramTypes passed in. (I could be reading this wrong,
so correct me.)
It seems like for 'P' we should only be sending '0' for numParams and NULL
for paramTypes. I don't see a scenario where sending anything else is
useful, because parse_analyse_varparams practically ignores it. (Why do
we even have to send these?)
The response from 'P' is an empty message.
For 'D', there are two routes. One is 'S' = describe a statement, the
other is 'P' describe a portal. I'm not clear what the difference is.
based on stuff I've seen here, it seems that 'S' is prepared statments,
and 'P' is for cursors. The second argument is the statement name (or the
cursor name)
It returns two things. First comes the parameters. The code is 't',
followed by the list length and the list of param types (Oids). Next
comes the RowDescription, which it seems is used elsewhere. (let me guess
- - for queries?)
So the implementation of PQprepare would look something like this.
(1) Send a 'P' message with the statmenet name and the query. Send 0 for
nParams and Null for paramTypes.
(2) Wait for an empty message.
(3) Send a 'D' 'S' <statement name> message.
(4) Wait for a response.
(5) Take the parameters and put it into a struct. Return a reference to
that struct.
(6) Discard the RowDescription as no one will be using them.
Comments on my rough outline and novice understanding accepted. I'll start
coding soon unless there are objections.
- --
Jonathan Gardner
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFBEdsCqp6r/MVGlwwRAk0YAKCU++UecV2oqJz77tfXGeck5xu3pQCgoQX5
kLHtQ/9XJrRjtmubohQl0Zk=
=U2Oa
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
