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

Поиск
Список
Период
Сортировка
От Dmitriy Igrishin
Тема Re: Feature request - CREATE TYPE ... WITH OID = oid_number.
Дата
Msg-id AANLkTimTNSGXJNJcBmdvFuv5xSz-QOeFZZfUcM7d2n-2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature request - CREATE TYPE ... WITH OID = oid_number.  (Merlin Moncure <mmoncure@gmail.com>)
Список 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@gmail.com>
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) :-)



--
// Dmitriy.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: wCTE behaviour
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: To Signal The postmaster