Psycopg psycopg

Comments and changes to this ticket

• You flagged this item as spam.
  

  Georges Racinet April 2nd, 2014 @ 08:04 PM

  Disclaimer: I'm not familiar with C extensions, nor with libpq

  This excerpt from large_object.c

  static int
  lobject_init(PyObject *obj, PyObject *args, PyObject *kwds)
  {
      int oid = (int)InvalidOid, new_oid = (int)InvalidOid;
      const char *smode = "";
      const char *new_file = NULL;
      PyObject *conn = NULL;
  
      if (!PyArg_ParseTuple(args, "O!|iziz",
           &connectionType, &conn,
           &oid, &smode, &new_oid, &new_file))
          return -1;
  
      return lobject_setup((lobjectObject *)obj,
          (connectionObject *)conn, (Oid)oid, smode, (Oid)new_oid, new_file);
  }
  

  seems at least to contradict the earlier declaration as T_UINT

  static struct PyMemberDef lobjectObject_members[] = {
      {"oid", T_UINT, offsetof(lobjectObject, oid), READONLY,
          "The backend OID associated to this lobject."},
      {"mode", T_STRING, offsetof(lobjectObject, smode), READONLY,
          "Open mode."},
      {NULL}
  };
  

  and this, from postgres_ext.h:

  /*
   * Object ID is a fundamental type in Postgres.
   */
  typedef unsigned int Oid;
  

  so, shouldn't we replace this 'int' by 'unsigned' ?

• 

  Daniele Varrazzo April 2nd, 2014 @ 09:11 PM

  • State changed from “new” to “open”

  I'll take a look at that but I think you are on the right track. Can't remember much of the lobject api: can you choose your own oid or are they only assigned by the server? If we can it would be nice to add operations with a large oid in the test suite.

  You can make a test yourself if you want to try and fix it: PyArg_ParseTuple and family should use I instead of i to parse an unsigned int, Docs are here. And we should probably use the Oid type were we are using ints.

  Thank you very much!

• 

  Daniele Varrazzo April 3rd, 2014 @ 01:36 AM

  • State changed from “open” to “resolved”

  Fixed the object opening: can you please check if the rest of the operations work as expected? Thank you!

• You flagged this item as spam.
  

  Georges Racinet April 3rd, 2014 @ 08:39 AM

  It works for me, both on the affected system/cluster and on my development rig, thanks a lot !

  Our code does just uses open/read/write/unlink (in particular, no import/export), so I can't speak for the rest of the API.
  I'm wondering why there was this cast to int in the first place, so don't hesitate to tell if you'd like a test of more functions on that particular cluster.

  As an unrelated side note, we're using zc.buildout and are affected by what looks to be the same problem as #18 while trying to 'develop' (affects also the gp.vcsdevelop extension, not surprising since it uses buildout's develop() function).

• 

  Daniele Varrazzo April 3rd, 2014 @ 10:25 AM

  I've seen that error reported more recently in bug #192

  For me it's a bug in setuptools: it doesn't apply the setup.cfg. I've reported it here: https://github.com/pypa/pip/issues/1630

  Opening a ticket to try and work around that.

• 

  Daniele Varrazzo April 3rd, 2014 @ 10:31 AM

  Open bug #204 to work on that.

• You flagged this item as spam.
  

  Georges Racinet April 3rd, 2014 @ 10:51 AM

  Great, I was considering building a custom 2.5.2.1-large-object-uid.tgz in the meanwhile, but I'll hold on.