简体   繁体   中英

Inserting integer array with postgresql in C (libpq)

I'm trying to post an integer array into my postgresql database. I'm aware that I could format everything as a string and then send that string as one SQL command. However, I believe the PQexecParams function should also bring some help. However, I'm kind of lost as how to use it.

    //we need to convert the number into network byte order
    int val1 = 131;
    int val2 = 2342;
    int val3[5] = { 0, 7, 15, 31, 63 };
    //set the values to use
    const char *values[3] = { (char *) &val1, (char *) &val2, (char *) val3 };
    //calculate the lengths of each of the values
    int lengths[3] = { sizeof(val1), sizeof(val2), sizeof(val3) * 5 };
    //state which parameters are binary
    int binary[3] = { 1, 1, 1 };

    PGresult *res = PQexecParams(conn, "INSERT INTO family VALUES($1::int4, $2::int4, $3::INTEGER[])", 3, //number of parameters
            NULL, //ignore the Oid field
            values, //values to substitute $1 and $2
            lengths, //the lengths, in bytes, of each of the parameter values
            binary, //whether the values are binary or not
            0); //we want the result in text format

Yes this is copied from some tutorial. However this returns :

 ERROR:  invalid array flags

Using a conventional method does work:

PQexec(conn, "INSERT INTO family VALUES (2432, 31, '{0,1,2,3,4,5}')");

Inserts data just fine, and I can read it out fine as well.

Any help would be greatly appreciated! :)

libpq 's PQexecParams can accept values in text or binary form.

For text values, you must sprintf the integer into a buffer that you put in your char** values array. This is usually how it's done. You can use text format with query parameters, there is no particular reason to fall back to interpolating the parameters into the SQL string yourself.

If you want to use binary mode transfers, you must instead ensure the integer is the correct size for the target field, is in network byte order, and that you have specified the type OID. Use htonl (for uint32_t ) or htons (for uint16_t ) for that. It's fine to cast away signedness since you're just re-ordering the bytes.

So:

  • You cannot ignore the OID field if you're planning to use binary transfer
  • Use htonl , don't brew your own byte-order conversion
  • Your values array construction is wrong. You're putting char** s into an array of char* and casting away the wrong type. You want &val1[0] or (equivalent in most/all real-world C implementations, but not technically the same per the spec) just val1 , instead of (char*)&val1
  • You cannot assume that the on-wire format of integer[] is the same as C's int32_t[] . You must pass the type OID INT4ARRAYOID (see include/catalog/pg_type.h or select oid from pg_type where typname = '_int4' - the internal type name of an array is _ in front of its base type) and must construct a PostgreSQL array value compatible with the typreceive function in pg_type for that type (which is array_recv ) if you intend to send in binary mode. In particular, binary-format arrays have a header . You cannot just leave out the header.

In other words, the code is broken in multiple exciting ways and cannot possibly work as written.

Really, there is rarely any benefit in sending integers in binary mode . Sending in text-mode is often actually faster because it's often more compact on the wire (small values). If you're going to use binary mode, you will need to understand how C represents integers, how network vs host byte order works, etc.

Especially when working with arrays, text format is easier.

libpq could make this a lot easier than it presently does by offering good array construct / deconstruct functions for both text and binary arrays. Patches are, as always, welcome. Right now, 3rd party libraries like libpqtypes largely fill this role.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM