Re: Feature request - CREATE TYPE ... WITH OID = oid_number.

From: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature request - CREATE TYPE ... WITH OID = oid_number.
Date: 2010-12-08 08:51:05
Message-ID: AANLkTimTNSGXJNJcBmdvFuv5xSz-QOeFZZfUcM7d2n-2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hey Merlin,

Do you mean that due to binary transfer it is possible
to determine the type of data transfered to the backend
and therefore there is no need to pass OIDs ?

2010/12/7 Merlin Moncure <mmoncure(at)gmail(dot)com>

> On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
> > On 12/07/2010 10:02 AM, Merlin Moncure wrote:
> >> On Tue, Dec 7, 2010 at 9:10 AM, Dmitriy Igrishin<dmitigr(at)gmail(dot)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) :-)
>

--
// Dmitriy.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-12-08 09:17:25 Re: pg_execute_from_file review
Previous Message Vlad Arkhipov 2010-12-08 08:50:05 Re: Slow BLOBs restoring