Tom Lane <tgl@sss.pgh.pa.us> writes:
> Malcolm Matalka <mmatalka@gmail.com> writes:
>> Hello, I'm implementing my own pgsql client for fun and I'm trying to
>> understand how to send a Parse message. The final parameter to Parse is
>> a series of Int32s with the description:
>> Specifies the object ID of the parameter data type. Placing a zero here
>> is equivalent to leaving the type unspecified.
>
>> But where do I find the list of object IDs?
>
> SELECT oid, typname FROM pg_type;
>
>> If so, It's not clear how to express some things. For example there is
>> a MONEYARRAYOID, but no MONEYOID.
>
> For historical reasons, the macro for money's OID is CASHOID.
> There's no grandfathered symbol for money[], though, so that
> gets a name constructed per standard rules (cf form_pg_type_symbol
> in genbki.pl).
>
> However, I fail to see why a generic client would need to know that.
> If you're hard-wiring OIDs into your code for anything beyond very
> basic types like int4, you're probably doing it wrong. Remember
Ok, it wasn't clear to me if and when I should pass this data in. I
couldn't find any documentation for this translating to performance
improvement, or addressing any possible errors due to ambiguity in
types. In general, should an interface no pass that information in on a
Parse? Is there a reason to do it?
> that PG is an extensible system and you may be called on to handle
> queries that deal with non-built-in types, so even if you had
> code for everything appearing in pg_type_d.h, it wouldn't be
> exhaustive. Better to look up type OIDs at runtime. In the case
> of Parse messages, you likely want to let the backend resolve
> the parameter types anyway, ie just send zeroes.
>
> regards, tom lane
Thank you for the detailed response