Re: [PATCHES] PQParam version 0.5
Andrew Chernow [EMAIL PROTECTED] writes: Here is the lastest pgparam patch. It is patched against a fresh checkout on 2007-12-05. What is this for? Why is it a good idea? It appears to be a fairly enormous increase in the size of libpq's API, and I really don't think I want to buy into the idea that libpq should know explicitly about each and every backend datatype. The 100% lack of any documentation in the patch isn't helping you sell it, BTW. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] PQParam version 0.5
Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: Here is the lastest pgparam patch. It is patched against a fresh checkout on 2007-12-05. What is this for? Why is it a good idea? It appears to be a fairly enormous increase in the size of libpq's API, and I really don't think I want to buy into the idea that libpq should know explicitly about each and every backend datatype. The 100% lack of any documentation in the patch isn't helping you sell it, BTW. regards, tom lane enormous increase in the size of libpq's API We can dramatically reduce the exports by using macros, if preferred. The 100% lack of any documentation Okay, we will do this. For starters, take a look at test.c. Below is a brief description: 1. Managed params, rather than manually building PQexecParam arrays; which is a little error prone and tedious. PQputint4(conn, 5); PQputtextptr(conn, abc); PQparamExec(conn, INSERT INTO t VALUES ($1, $2), 1, NULL); // the NULL arg is a PGresult**, which is auto-cleared // when NULL. Otherwise *result is assigned. // or use the print-style: we changed the argument order since // our last release, it felt off. PGresult *r; PQparamExecf(conn, SELECT * FROM foo(%d, %t), 1, r, 5, abc); 2. In binary result mode, the user has no idea how the data is formatted and there are no demarshaling functions, thus making the binary parameterized API impractical. So, we made PQget functions that support text or binary results. The benefit of supporting both is that the new PQget functions can be used regardless of how the query was executed. long long i8; PGinet inet; PQgetint8(res, 0, 0, i8); PQgetinet(res, 0, 1, inet); // coming soon. Currently, no way of doing this now. PGarr arr; int item, itemlen; PQgetarr(res, 0, 0, arr); // access 2 dim 2d array - arr[2][7] itemlen = PQgetarr2d(arr, item, 2, 7); 3. Client server should both understand how data is formatted over the wire, otherwise the data received by the client is not useful. Things like int4 or even a BOX are not that tricky, but other types are or may change between versions. 4. Why do atoi(PQgetvalue(...)) everywhere? Andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] PQParam version 0.5
Here is the lastest pgparam patch. It is patched against a fresh checkout on 2007-12-05. This release adds support for printf-style param puts/execs. Instead of having to do a PQputX for each param, you can use a format string and put multiple params. PQputf(), PQparamExecf() and PQparamSendf() support this. See release notes and conversion specifiers for details. Also changed PQputint8's prototype. Previously, it was using a void* as the value argument, due to a lack of a portable 64-bit type in libpq. We found an intersting way around this by using macro and variable argument tricks. Andrew Merlin pgparam-0.5-patch.tgz Description: application/compressed ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PQParam version 0.5
On Dec 5, 2007 2:44 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: Andrew Chernow escribió: Also changed PQputint8's prototype. Previously, it was using a void* as the value argument, due to a lack of a portable 64-bit type in libpq. We found an intersting way around this by using macro and variable argument tricks. I didn't read the patch, but variadic macros are not portable. FWIW uint64 should portable to all platforms that have it (and it should be 32 bits on platforms that don't), but you have to watch for INT64_IS_BUSTED. we don't use variadic macros...just a macro wrapper to a variadic function. merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] PQParam version 0.5
Andrew Chernow escribió: Also changed PQputint8's prototype. Previously, it was using a void* as the value argument, due to a lack of a portable 64-bit type in libpq. We found an intersting way around this by using macro and variable argument tricks. I didn't read the patch, but variadic macros are not portable. FWIW uint64 should portable to all platforms that have it (and it should be 32 bits on platforms that don't), but you have to watch for INT64_IS_BUSTED. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. (L. Torvalds) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] PQParam version 0.5
Merlin Moncure wrote: On Dec 5, 2007 2:44 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: Andrew Chernow escribió: Also changed PQputint8's prototype. Previously, it was using a void* as the value argument, due to a lack of a portable 64-bit type in libpq. We found an intersting way around this by using macro and variable argument tricks. I didn't read the patch, but variadic macros are not portable. FWIW uint64 should portable to all platforms that have it (and it should be 32 bits on platforms that don't), but you have to watch for INT64_IS_BUSTED. we don't use variadic macros...just a macro wrapper to a variadic function. merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq Taken from libpq-fe.h #define PQputint8(conn, i8) PQputint8v(conn, sizeof(i8), i8) /* Function subject to change. Do not use directly, see PQputint8. */ extern int PQputint8v(PGconn *conn, size_t valsize, ...); // goal was pass by value, not by ptr, which was our first solution PQputint8(conn, 12345678912345LL); The problem is libpq has no public 64-bit data type to use with the PQputint8 prototype. But! if we make PQputint8 a macro that wraps a variadic function, we get around the data type issue. Since libpq doesn't have a public 64-bit portable data type, we felt this was done for a good reason. We didn't want to break that convention. andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
