Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.9.1/8.9.1) with ESMTP id SAA21012 for ; Tue, 10 Nov 1998 18:27:06 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA06737; Tue, 10 Nov 1998 18:19:31 -0500 (EST) To: "Bryan White" cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] Determine data type of columns In-reply-to: Your message of Tue, 10 Nov 1998 16:21:26 -0500 <012001be0cf0$131ffb60$a3f0f6ce@bryan.arcamax.com> Date: Tue, 10 Nov 1998 18:19:30 -0500 Message-ID: <6735.910739970@sss.pgh.pa.us> From: Tom Lane "Bryan White" writes: > This brings me to my question. The PQftype function returns an OID but I > don't see any documentation on how to interpret it. Are the values constant > for the built in types (specifically int4, text, and date)? The OID for a type is the OID of the row for the type in the system table pg_type. Try select oid,* from pg_type; and much will become clear. You can go from type name to OID and vice versa with appropriate queries on pg_type. OIDs for the system-defined types should be the same across all installations. OIDs for user-defined types are likely to change if you initdb and reload the database. > Is there a way to encode the values in an insert/update statement such that > they will be quietly converted to the proper type on the backend? You should be able to do something like '42'::int4 for any standard type --- they all have string-to-datatype converters. The parser essentially does the above for you when it sees an unadorned 42. It will also supply a free conversion from string literal to most of the more complicated types (datetime, for instance). I imagine that as an error-detection measure it will not supply a free string-to-int or string-to-float conversion --- you have to write the cast if you want a string literal to be read as an int or float. regards, tom lane