From: Florian Weimer <fw@deneb.enyo.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Type OIDs
References: <877hztupfn.fsf@mid.deneb.enyo.de>
 <10172.1244057188@sss.pgh.pa.us>
Date: Sat, 06 Jun 2009 12:32:07 +0200
In-Reply-To: <10172.1244057188@sss.pgh.pa.us> (Tom Lane's message of "Wed, 03
	Jun 2009 15:26:28 -0400")
Message-ID: <87r5xxwt3s.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

* Tom Lane:

> Florian Weimer <fw@deneb.enyo.de> writes:
>> Can I embed the types I'm interested in into my program, or should I
>> query the server at least once per connection to get the mapping?  I'm
>> interested in types such as INTEGER, TEXT, BYTEA, etc.  No user
>> defined types, and nothing fancy.  Ultra-long-term portability isn't
>> required, either.
>
> Well, the type OIDs of the standard built-in types haven't changed in
> at least ten years, but that doesn't mean we won't change 'em in the
> future.  I'd advise at least using the #define's from pg_type.h rather
> than writing actual numeric constants.

Okay, will do that. Thanks.

By the way, the binary encoding would be pretty useful for BYTEA
columns and parameters, but it's a pretty hefty burden for almost
anything else.  Wouldn't it make sense to add a format flag which
basically says "binary if it's BYTEA, otherwise text"?  I don't think
many host languages make a strong distinction between BYTEA and TEXT
types (except those which use UTF-16 and expose that to the user, like
Java and C#).  As a result, it is difficult to specify the right types
when talking to the server.  You don't want to label a column as BYTEA
overeagerly because it will break type inference on the SQL side (I
think).