From: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Type OIDs |
Date: | 2009-06-06 10:32:07 |
Message-ID: | 87r5xxwt3s.fsf@mid.deneb.enyo.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
* Tom Lane:
> Florian Weimer <fw(at)deneb(dot)enyo(dot)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).
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-06 15:15:02 | Re: Type OIDs |
Previous Message | Joe Conway | 2009-06-04 01:18:22 | Re: Type OIDs |