Thread: OID's
Доброго времени суток, господа. У меня вопрос относительно автоматической колонки oid, которая создается, если не отказаться специально (WITHOUT OID). Хотелось бы знать, может где-то хранятся все OID или как узнать перед вставкой данных в таблицу, который OID будет использован. Этот вопрос также задан на pgsql-sql, но пока внятного разъяснения нет. -- С уважением, Mihail Наседкин mailto:m.nasedkin.perm@mail.ru
Mihail Nasedkin wrote: > Доброго времени суток, господа. > > У меня вопрос относительно автоматической колонки oid, которая > создается, если не отказаться специально (WITHOUT OID). > > Хотелось бы знать, может где-то хранятся все OID или как узнать перед > вставкой данных в таблицу, который OID будет использован. Хрянятся в таблице, как еще один столбец. Узнать перед вставкой -- вряд ли, особенно в многопользовательской среде. А зачем все это? Я вот с радостью отключил OID по дефолту в 8.0, ибо надобность в них сомнительная. -- Best regards, Nick (GPG Key ID: 4396B2D0)
Здравствуйте. Спасибо Nick за ответ от 21 января 2005 г., 14:25:49 на мой вопрос: >> У меня вопрос относительно автоматической колонки oid, которая >> создается, если не отказаться специально (WITHOUT OID). >> >> Хотелось бы знать, может где-то хранятся все OID или как узнать перед >> вставкой данных в таблицу, который OID будет использован. NG> Хрянятся в таблице, как еще один столбец. Узнать перед вставкой -- вряд NG> ли, особенно в многопользовательской среде. Это понятно всем, но в какой системной таблице хранятся ВСЕ OID's, а не только этой таблицы. Есть таблица "pg_catalog.pg_attribute" с полем "attrelid", где хранятся все системные OID's, но нужны именно пользовательские OID's. NG> А зачем все это? Я вот с радостью отключил OID по дефолту в 8.0, ибо NG> надобность в них сомнительная. Мое мнение в том, что система уникальности записи в пределах всех баз данных конкретной инсталляции PostgreSQL независимо от принадлежности к конкретной таблице является интересным для нестандартных решений в приложениях. Конечно можно такую задачу решать каждому разработчику своими силами и это реализовано в других SQL-серверах. Однако, если уникальность уже реализована на системном уровне сервера - это большой плюс PostgreSQL. Я всегда использую OID's. В моем случае задача в том, чтобы использовать все пользовательские OID's в некотором запросе с LEFT JOIN. Использовать UNION категорически против. Система скрозной OID является своего рода осью на которую можно "нанизать" нужные записи нужных таблиц. Для чего? Продолжение при интересе :) -- С уважением, Mihail Наседкин mailto:m.nasedkin.perm@mail.ru
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-684387517-1106305053=:14628 Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 21 Jan 2005, Mihail Nasedkin wrote: > Доброго времени суток, господа. > > У меня вопрос относительно автоматической колонки oid, которая > создается, если не отказаться специально (WITHOUT OID). > > Хотелось бы знать, может где-то хранятся все OID или как узнать перед > вставкой данных в таблицу, который OID будет использован. > > Этот вопрос также задан на pgsql-sql, но пока внятного разъяснения > нет. Вот так с лету ответить не смогу, но дам наводку: http://www.pgsql.ru/db/pgsearch/index.html?q=oid+last+inserted > > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---559023410-684387517-1106305053=:14628--
Спасибо Олег за ответ от 21 января 2005 г., 15:57:33: >> У меня вопрос относительно автоматической колонки oid, которая >> создается, если не отказаться специально (WITHOUT OID). >> >> Хотелось бы знать, может где-то хранятся все OID или как узнать перед >> вставкой данных в таблицу, который OID будет использован. >> >> Этот вопрос также задан на pgsql-sql, но пока внятного разъяснения >> нет. OB> Вот так с лету ответить не смогу, но дам наводку: OB> http://www.pgsql.ru/db/pgsearch/index.html?q=oid+last+inserted Посмотрю. Знаю, что есть такое свойство у объекта statement драйвера DBD::Pg - pg_oid_status в котором сохраняется последний вставленный OID для текущего statement. Конечно это можно использовать и вручную сохранять OID в своей таблице. Только мне хотелось выяснить, может это уже делает система сервера. -- С уважением, Mihail mailto:m.nasedkin.perm@mail.ru
>Знаю, что есть такое свойство у объекта statement драйвера DBD::Pg - pg_oid_status >в котором сохраняется последний вставленный OID для текущего statement. Конечно >это можно использовать и вручную сохранять OID в своей таблице. Только >мне хотелось выяснить, может это уже делает система сервера. > > > Если мне не изменяет память, то в каком-то мануале говорилось, что номера oid идут не по порядку. И таким образом толку от последнего сохранённого никакого нет. Далеко не факт, что следующий oid будет старый oid + 1. -- С уважением, Виктор
On Fri, Jan 21, 2005 at 02:52:01PM +0500, Mihail Nasedkin wrote: > NG> Хрянятся в таблице, как еще один столбец. Узнать перед вставкой -- вряд > NG> ли, особенно в многопользовательской среде. > > Это понятно всем, но в какой системной таблице хранятся ВСЕ OID's, а > не только этой таблицы. Есть таблица "pg_catalog.pg_attribute" с полем > "attrelid", где хранятся все системные OID's, но нужны именно > пользовательские OID's. attrelid в данном случае - лишь ссылка на pg_catalog.pg_class.oid. ВСЕ системные таблицы имеют столбец oid, и именно это его основное назначение. > NG> А зачем все это? Я вот с радостью отключил OID по дефолту в 8.0, ибо > NG> надобность в них сомнительная. > Мое мнение в том, что система уникальности записи в пределах всех баз > данных конкретной инсталляции PostgreSQL независимо от принадлежности > к конкретной таблице является интересным для нестандартных решений в > приложениях. Конечно можно такую задачу решать каждому разработчику > своими силами и это реализовано в других SQL-серверах. > Однако, если уникальность уже реализована на системном уровне сервера - это большой > плюс PostgreSQL. Я всегда использую OID's. Чем не вариант - уникальность с помощью SEQUENCE, тоже на уровне сервера? Конечно, между базами уникальности не получится, а вот между всеми таблицами в базе - вполне. К тому же, если не ошибаюсь, oid - поле 32-битное, тогда как значение в SEQUENCE - 64-битное, что даёт бОльшую гарантию, что значение не переполнится на больших объёмах данных. И можно заранее достать значение, которое больше никем использовано не будет. -- Fduch M. Pravking
Здравствуйте, сообщество pqsql-ru-general и Alexander. AMP> On Fri, Jan 21, 2005 at 02:52:01PM +0500, Mihail Nasedkin wrote: >> NG> Хрянятся в таблице, как еще один столбец. Узнать перед вставкой -- вряд >> NG> ли, особенно в многопользовательской среде. >> >> Это понятно всем, но в какой системной таблице хранятся ВСЕ OID's, а >> не только этой таблицы. Есть таблица "pg_catalog.pg_attribute" с полем >> "attrelid", где хранятся все системные OID's, но нужны именно >> пользовательские OID's. AMP> attrelid в данном случае - лишь ссылка на pg_catalog.pg_class.oid. AMP> ВСЕ системные таблицы имеют столбец oid, и именно это его основное AMP> назначение. >> NG> А зачем все это? Я вот с радостью отключил OID по дефолту в 8.0, ибо >> NG> надобность в них сомнительная. >> Мое мнение в том, что система уникальности записи в пределах всех баз >> данных конкретной инсталляции PostgreSQL независимо от принадлежности >> к конкретной таблице является интересным для нестандартных решений в >> приложениях. Конечно можно такую задачу решать каждому разработчику >> своими силами и это реализовано в других SQL-серверах. >> Однако, если уникальность уже реализована на системном уровне сервера - это большой >> плюс PostgreSQL. Я всегда использую OID's. AMP> Чем не вариант - уникальность с помощью SEQUENCE, тоже на уровне сервера? AMP> Конечно, между базами уникальности не получится, а вот между всеми AMP> таблицами в базе - вполне. К тому же, если не ошибаюсь, oid - поле AMP> 32-битное, тогда как значение в SEQUENCE - 64-битное, что даёт бОльшую AMP> гарантию, что значение не переполнится на больших объёмах данных. 4 биллиона уникальных значений зачастую достаточно :) AMP> И можно заранее достать значение, которое больше никем использовано не AMP> будет. Частные решения конкретного программиста останутся с ним, а системный подход может пригодится для всех. -- С уважением, Mihail mailto:m.nasedkin.perm@mail.ru
On Mon, Jan 24, 2005 at 09:05:32AM +0500, Mihail Nasedkin wrote: > Здравствуйте, сообщество pqsql-ru-general и Alexander. > > AMP> Чем не вариант - уникальность с помощью SEQUENCE, тоже на уровне сервера? > AMP> Конечно, между базами уникальности не получится, а вот между всеми > AMP> таблицами в базе - вполне. К тому же, если не ошибаюсь, oid - поле > AMP> 32-битное, тогда как значение в SEQUENCE - 64-битное, что даёт бОльшую > AMP> гарантию, что значение не переполнится на больших объёмах данных. > 4 биллиона уникальных значений зачастую достаточно :) 640 K, несомненно, хватит для всех! (c) :) > AMP> И можно заранее достать значение, которое больше никем использовано не > AMP> будет. > Частные решения конкретного программиста останутся с ним, а системный > подход может пригодится для всех. Не совсем понял, в чём здесь частность решения. Последовательности задумывались специально для этих целей, и, кстати, сильно выигрывают по отношению к тем же mysql'ским auto_increment в том, что у них нет строгой привязки к конкретному столбцу. Программисту надо лишь выбрать, либо он сначала делает SELECT nextval, потом INSERT с полученным значением, либо сначала INSERT со значением по умолчанию, потом SELECT currval. -- Fduch M. Pravking
AMP> On Mon, Jan 24, 2005 at 09:05:32AM +0500, Mihail Nasedkin wrote: >> Здравствуйте, сообщество pqsql-ru-general и Alexander. >> >> AMP> Чем не вариант - уникальность с помощью SEQUENCE, тоже на уровне сервера? >> AMP> Конечно, между базами уникальности не получится, а вот между всеми >> AMP> таблицами в базе - вполне. К тому же, если не ошибаюсь, oid - поле >> AMP> 32-битное, тогда как значение в SEQUENCE - 64-битное, что даёт бОльшую >> AMP> гарантию, что значение не переполнится на больших объёмах данных. >> 4 биллиона уникальных значений зачастую достаточно :) AMP> 640 K, несомненно, хватит для всех! (c) :) Я указал "зачастую", а не "для всех" :) >> AMP> И можно заранее достать значение, которое больше никем использовано не >> AMP> будет. >> Частные решения конкретного программиста останутся с ним, а системный >> подход может пригодится для всех. AMP> Не совсем понял, в чём здесь частность решения. Последовательности AMP> задумывались специально для этих целей, и, кстати, сильно выигрывают по AMP> отношению к тем же mysql'ским auto_increment в том, что у них нет AMP> строгой привязки к конкретному столбцу. AMP> Программисту надо лишь выбрать, либо он сначала делает SELECT nextval, AMP> потом INSERT с полученным значением, либо сначала INSERT со значением по AMP> умолчанию, потом SELECT currval. Убедительно, спасибо Александр. -- С уважением, Mihail mailto:m.nasedkin.perm@mail.ru