Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1X75Ib-0007vs-72 for pgsql-interfaces@arkaria.postgresql.org; Tue, 15 Jul 2014 16:09:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1X75Ia-0006Uv-G4 for pgsql-interfaces@arkaria.postgresql.org; Tue, 15 Jul 2014 16:09:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1X75IZ-0006Sp-MZ for pgsql-interfaces@postgresql.org; Tue, 15 Jul 2014 16:09:47 +0000 Received: from mail-pa0-f48.google.com ([209.85.220.48]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1X75IW-000562-Lb for pgsql-interfaces@postgresql.org; Tue, 15 Jul 2014 16:09:45 +0000 Received: by mail-pa0-f48.google.com with SMTP id et14so2090140pad.35 for ; Tue, 15 Jul 2014 09:09:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:mime-version:content-transfer-encoding; bh=CGuCYg8qpX/Nu+pLXTbQgNKdWZaDz93+K9rYRoon5Ug=; b=Isp1mV3SNZa0sdQ4ZBbmTawTZhqOzJR8d06NTm3HsOobZYayLiGJh+ckaxTfsODOAQ TNbftRZfRL8iDj2LRq4POlYa0Va3+bJkFRaFCBxyK5pnnEX7v428+znufRNlaJVr9G2t Ts6Vau9zU5dy9FsVymUA7DfJw87EsHuvLqVhZ+jbWyepD7oS/hJxgKdTiTF+Iv1dwOLz N8mIAnAavjHBqTvfRU4LfcOnjhRyX/JQufW0dKxIibTxg8o5j/BumyOK1bplPc00nwDP UaQS4KMjwDOSBlzL2IZM8f0ZoXy3d2wtZGIzqEbdKclfVSnKo6bGhCZfUzcz+hj21k4h H6DQ== X-Gm-Message-State: ALoCoQmkxpZhi8CA9DJ3UfXaZfEjy3Lm4My6F3TU5et2jTjsva5aWcRrHrtWLz8nvxPOYw5VV2So X-Received: by 10.66.251.233 with SMTP id zn9mr23894139pac.67.1405440583313; Tue, 15 Jul 2014 09:09:43 -0700 (PDT) Received: from [192.168.0.107] (c-69-181-249-16.hsd1.ca.comcast.net. [69.181.249.16]) by mx.google.com with ESMTPSA id ak1sm14378835pbc.58.2014.07.15.09.09.42 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 15 Jul 2014 09:09:42 -0700 (PDT) Message-ID: <1405440583.15301.10.camel@jeff-desktop> Subject: Re: C where are oids defined? From: Jeff Davis To: frank ernest Cc: pgsql-interfaces@postgresql.org Date: Tue, 15 Jul 2014 09:09:43 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-interfaces Precedence: bulk Sender: pgsql-interfaces-owner@postgresql.org On Tue, 2014-07-15 at 17:36 +0200, frank ernest wrote: > Hi, I'm new and I can't seem to figure out what values are permitted for OID > PQexecPrepared(parrentcon, insertstmt, 2, argz_str, //fixme); > I've looked in the docs but it's simply evading me. In C the values are of type char * and in the database they are of type varchar(255). It looks like you're talking about PQprepare(), not PQexecPrepared(). You can just use NULL for the paramTypes argument, and normally postgres will figure out the type and everything will be fine. Specifying the types might catch certain kinds of mistakes and might save postgres a small amount of work. To specify the types, the OID is the internal ID of the postgres type. For built-in types, this is constant, and most people #include "catalog/pg_type.h". That allows you to use a name, like VARCHAROID, INT4OID, etc. For user-defined types, the OID might be different on different servers, so it's quite awkward to specify the OID for a user-defined type. Regards, Jeff Davis -- Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-interfaces