Re: [PATCHES] [PATCH] automatic integer conversion
[EMAIL PROTECTED] wrote: Hello! Here is patch which makes libpq more confortable when working with binary integers. Automatic conversion intialized by PQsetconvertint(conn,1), so old applications continues to work proper. This seems to depend on byteswap.h which doesn't look like a portable interface. Please note that I'm not saying that fixing that issue means the patch is acceptable. Personally I'm not sure that this is a worthy goal you are pursuing here. Wouldn't it be a good idea to propose the feature first and write the code later? -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J Aprender sin pensar es inútil; pensar sin aprender, peligroso (Confucio) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [PATCH] automatic integer conversion
Alvaro Herrera [EMAIL PROTECTED] writes: Please note that I'm not saying that fixing that issue means the patch is acceptable. Personally I'm not sure that this is a worthy goal you are pursuing here. Wouldn't it be a good idea to propose the feature first and write the code later? Indeed. For starters, if we are going to try to provide serious support in libpq for binary-format parameters, it probably ought to cover more than just integers. OTOH, I think we've already seen where that line of thought leads, and it looks pretty ugly too: http://archives.postgresql.org/pgsql-patches/2007-12/msg00014.php Anyway, I'd like to see a design discussion about what any libpq API changes in this area ought to look like, rather than having it be determined by who can submit the quickest-and-dirtiest patch. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [PATCH] automatic integer conversion
On Dec 8, 2007 6:50 PM, Tom Lane [EMAIL PROTECTED] wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Please note that I'm not saying that fixing that issue means the patch is acceptable. Personally I'm not sure that this is a worthy goal you are pursuing here. Wouldn't it be a good idea to propose the feature first and write the code later? Indeed. For starters, if we are going to try to provide serious support in libpq for binary-format parameters, it probably ought to cover more than just integers. OTOH, I think we've already seen where that line of thought leads, and it looks pretty ugly too: http://archives.postgresql.org/pgsql-patches/2007-12/msg00014.php Anyway, I'd like to see a design discussion about what any libpq API changes in this area ought to look like, rather than having it be determined by who can submit the quickest-and-dirtiest patch. A major overhaul of this patch is coming...we are addressing some of the issues that were raised. I think that this is an important issue that needs to be solved. Dealing with arrays is a complete mess, and many other things are more difficult than they have to be. User defined types are problem as well, and marshaling everything into text is always a good solution. In the long term, my opinion is that postgresql types have to be converted into a more pluggable interface that is available into both the client and the server. It doesn't really make sense to reimplement the send/receive routines in both the client and the server...and the patch that we proposed (ditto the OP) did not really leave room for this in the future. That said, I strongly feel that libpq should in some fashion do a better job in handling binary data than it currently does. Andrew and I are taking this into consideration and will submit a proposal that we hope that should hopefully deal with things in a more acceptable way. We understand the ramifications of extending the libpq api. merlin ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] [PATCH] automatic integer conversion
Hello!
Here is patch which makes libpq more confortable when working with binary
integers.
Automatic conversion intialized by PQsetconvertint(conn,1), so old applications
continues to work proper.
--
diff -ur postgresql-8.2.4.orig/src/interfaces/libpq/exports.txt
postgresql-8.2.4/src/interfaces/libpq/exports.txt
--- postgresql-8.2.4.orig/src/interfaces/libpq/exports.txt 2006-08-18
23:52:39.0 +0400
+++ postgresql-8.2.4/src/interfaces/libpq/exports.txt 2007-11-26
16:23:25.0 +0300
@@ -136,3 +136,6 @@
PQdescribePortal 134
PQsendDescribePrepared135
PQsendDescribePortal 136
+PQsetconvertint 137
+PQisconverrtint 138
+PQexecPreparedParams 139
diff -ur postgresql-8.2.4.orig/src/interfaces/libpq/fe-exec.c
postgresql-8.2.4/src/interfaces/libpq/fe-exec.c
--- postgresql-8.2.4.orig/src/interfaces/libpq/fe-exec.c2006-10-04
04:30:13.0 +0400
+++ postgresql-8.2.4/src/interfaces/libpq/fe-exec.c 2007-11-26
16:20:28.0 +0300
@@ -12,16 +12,21 @@
*
*-
*/
+#include postgres.h
#include postgres_fe.h
#include ctype.h
#include fcntl.h
+#include endian.h
+#include byteswap.h
#include libpq-fe.h
#include libpq-int.h
#include mb/pg_wchar.h
+#include catalog/pg_type.h
+
#ifdef WIN32
#include win32.h
#else
@@ -879,6 +884,43 @@
resultFormat);
}
+
+/*
+ * PQsendQueryPreparedParams
+ * Like PQsendQuery, but execute a previously prepared statement,
+ * parameters passed as helpers for integer converting
+ */
+int
+PQsendQueryPreparedParams(PGconn *conn,
+ const char *stmtName,
+ int nParams,
+ const Oid *paramTypes,
+ const char *const * paramValues,
+ const int *paramLengths,
+ const int *paramFormats,
+ int resultFormat)
+{
+ if (!PQsendQueryStart(conn))
+ return 0;
+
+ if (!stmtName)
+ {
+ printfPQExpBuffer(conn-errorMessage,
+ libpq_gettext(statement name is a null
pointer\n));
+ return 0;
+ }
+
+ return PQsendQueryGuts(conn,
+ NULL,/* no command
to parse */
+ stmtName,
+ nParams,
+ paramTypes,
+ paramValues,
+ paramLengths,
+ paramFormats,
+ resultFormat);
+}
+
/*
* Common startup code for PQsendQuery and sibling routines
*/
@@ -1003,6 +1045,13 @@
if (paramValues paramValues[i])
{
int nbytes;
+ char const *val;
+ union
+ {
+ uint64 i64;
+ uint32 i32;
+ uint16 i16;
+ } tmpint;
if (paramFormats paramFormats[i] != 0)
{
@@ -1021,8 +1070,33 @@
/* text parameter, do not use paramLengths */
nbytes = strlen(paramValues[i]);
}
+ #if __BYTE_ORDER == __LITTLE_ENDIAN
+ if (conn-convert_int paramTypes
+ (paramTypes[i]==INT2OID || paramTypes[i]==INT4OID ||
+paramTypes[i]==INT8OID))
+ {
+ switch(nbytes)
+ {
+ case 2:
+
tmpint.i16=bswap_16(*(uint16*)paramValues[i]);
+ val=(char*)tmpint;
+ break;
+ case 4:
+
tmpint.i32=bswap_32(*(uint32*)paramValues[i]);
+ val=(char*)tmpint;
+ break;
+ case 8:
+
tmpint.i64=bswap_64(*(uint64*)paramValues[i]);
+ val=(char*)tmpint;
+ break;
+ default:
+ val=paramValues[i];
+ }
+
