On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> On 12/07/2010 10:02 AM, Merlin Moncure wrote:
>> On Tue, Dec 7, 2010 at 9:10 AM, Dmitriy Igrishin<dmitigr@gmail.com>
>> wrote:
>>>
>>> Hey hackers@,
>>>
>>> libpq execution function works with OIDs. In some cases it is
>>> highly recommended specify OIDs of parameters according to
>>> libpq documentation.
>>> While developing a database application with libpq and if
>>> application works with custom data types IMO reasonable to
>>> provide developer extended type creation syntax, e.g.
>>> CREATE TYPE my_type ... WITH OID = 12345;
>>> Yes, it is possible to make dump of the database with oids,
>>> but if developer prefer to hard code OIDs in the application it
>>> would be more convenient for him to use syntax above.
>>> Btw, there is already Oid lo_import_with_oid function in large
>>> objects libpq's API which are very useful.
>>
>> It's possible to do this in 9.0 in a slightly indirect way. See the
>> contrib/pg_upgrade folder. In particular, grep for
>> set_next_pg_type_oid.
>>
>
> This doesn't strike me as very good advice. Those things are not exposed
> generally for good reason. The right way to do this surely is to have the
> app look up and cache the OIDs it needs rather than hardcode the values in
> the application.
Note he didn't provide reasons why he is asking for this power. Your
assertion is a coded variant of "don't use the binary protocol" which
I happen to think is not very good advice IF you know what you're
doing. We plan on using this feature to support binary transfer of
data between databases through the variadic dblink library we maintain
that uses binary format (but pre 9.0 it reverts to text in many
cases). This can be 2x or more faster than stock dblink in real world
cases.
merlin
(your advice is generally correct however) :-)