Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.3/8.9.3) with ESMTP id SAA96397
	for <pgsql-interfaces@postgreSQL.org>;
	Sun, 2 May 1999 18:37:22 -0400 (EDT)
	(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 SAA16189
	for <pgsql-interfaces@postgreSQL.org>;
	Sun, 2 May 1999 18:36:41 -0400 (EDT)
To: pgsql-interfaces@postgreSQL.org
Subject: Field types (was Re: Return value of int)
In-reply-to: Your message of Sun, 2 May 1999 15:35:03 -0400 (EDT)
	<m10e211-0000bIC@druid.net>
Date: Sun, 02 May 1999 18:36:41 -0400
Message-ID: <16187.925684601@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> Regarding this, it would be nice if libpq had some official, documented
> way of determining the type of the field.  Currently I deal with this
> in PyGreSQL by stealing some #defines from src/include/catalog/pg_type.h,
> something that isn't normally available to application programmers.

Well, I don't see a big problem with stealing the defines --- the odds
of the OID for INT4, say, ever changing are pretty low.

But of course the "official, documented" way to find out what a given
type OID means is

	SELECT typname FROM pg_type WHERE oid = <whatever>;

If you kept a cache of type info on the application side, you could
probably even make this fast enough to be a reasonable approach :-)

			regards, tom lane