Re: Object IDs in Parse message

--=-=-=
Content-Type: text/plain


Tom Lane <[email protected]> writes:

> Malcolm Matalka <[email protected]> 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

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEQP2ClpgOfnguJZS++DiEc/oMrtcFAl1vakQACgkQ+DiEc/oM
rtdF9AgAv8jZ+jXMZx6qCyFyhLgjSjKCVWKfs6c3cGvPeCRKH3arxRD9Rkxy1Jhj
JUC43Bsf+id4JvKWMp415A73xn+0vgPxEs++RvQuYCraTh2sYpaA+qt1vT7m/NeZ
OoJ9S1b0HBzeJWPqwnE3rlmb3sHrrPuJJ+ppB/+yXxLFVzCwH+Q5mXNvW1SHAlEb
6m3CROVQtEQByiJfdbYO613SwoE292TNh4wo/DoClaDyShH2J++GFXQ90Y9aTa6x
HhB6OIDmf6yG9ZU8fpdFtYLc08gYo5DFG2hnV9ZRv3OqU+3MjtvGDPtMjXV5pn41
xLa8TJdKHYb6WG6RI7hOOipn+t6wAw==
=HqdM
-----END PGP SIGNATURE-----
--=-=-=--