The reasons are simple, particularly, I don't want to bloat SQL with CAST or ::. Its not elegant and looks ugly. If I need to bind e.g. int or short I don't want write ::integer or ::smallint in SQL, because I can easily map int to integer via OID... I don't clearly understand how set_next_pg_type_oid code can helps me. Also I don't understand why cache of OIDs can't be used to get results via PQexecParams in a binary form ? I can do it. Querying the db for OIDs seems to me a good idea. But: 1. Since the structure of pg_type system catalog can be changed the developer must be able to determine a libpq version to be able to implement cross libpq-version of the product (especially library). So PQversion() should be there :-) 2. To avoid memory overheads (especially in WEB environments) it would be nice if libpq will keep cache of types metadata as a static structure per database and provide an API to work with (in this case I totally agree with Pavel). At least, the API should support rereading the cache. In this case 1. (PQversion) is not needed -- libpq care it itself :-)
2010/12/7 Pavel Stehule <pavel.steh...@gmail.com> > 2010/12/7 Tom Lane <t...@sss.pgh.pa.us>: > > Merlin Moncure <mmonc...@gmail.com> writes: > >> On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Say what? He didn't say that, he said "don't assume that user-defined > >>> types have hard-wired OIDs". > > > >> Well, you're right, strictly speaking. Of course, the OP is not > >> assuming it, he is enforcing it. > > > > No, he's wishing he could enforce it. Which will work, mostly, until > > the day it doesn't because of a pre-existing collision. And then he'll > > be up the creek with a lot of software that he can't fix readily. I > > concur with Andrew's advice: don't go there in the first place. Use a > > cache to mitigate the costs of looking up user-defined OIDs, and you > > won't regret it later. > > > > I had to solve similar task, and probably I am not alone. Can pg > supports some cache and some API for "custom oid"? Now, a work with > custom types on C level is little bit unfriendly. There isn't a > problem with builtin types - these are well defined. I agree, so > direct access to oids for custom types isn't a good idea. But some > general API or pattern can be nice - mainly for client side. > > regards > > Pavel > > > regards, tom lane > > > > -- > > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-hackers > > > -- // Dmitriy.
