X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 9B5E73A52DB for ; Mon, 24 Jan 2005 03:59:20 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 22850-02 for ; Mon, 24 Jan 2005 03:59:17 +0000 (GMT) Received: from mail.ccl.ru (mail.ccl.ru [195.222.130.78]) by svr1.postgresql.org (Postfix) with ESMTP id 99E263A5327 for ; Mon, 24 Jan 2005 03:59:15 +0000 (GMT) Received: from s02.mz.intra (mail.mz.perm.ru [195.222.139.86]) by mail.ccl.ru (8.13.1/8.13.1) with ESMTP id j0O3xAQl025830 for ; Mon, 24 Jan 2005 08:59:12 +0500 (YEKT) Received: from server1c ([192.168.22.73]) by s02.mz.intra with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jan 2005 08:57:54 +0500 Date: Mon, 24 Jan 2005 08:57:43 +0500 From: Mihail Nasedkin X-Mailer: The Bat! (v2.00) CD5BF9353B3B7091 Reply-To: Mihail Nasedkin X-Priority: 3 (Normal) Message-ID: <214299421.20050124085743@mail.ru> To: pgsql-sql@postgresql.org Subject: Re: OID's In-Reply-To: <20050121170438.GA56550@winnie.fuhr.org> References: <3628044953.20050120154558@mail.ru> <20050120164830.GB41081@winnie.fuhr.org> <8411982406.20050121111734@mail.ru> <20050121170438.GA56550@winnie.fuhr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2005 03:57:54.0530 (UTC) FILETIME=[E1EB2C20:01C501C8] X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.224 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200501/204 X-Sequence-Number: 19992 Hello, pgsql-sql and Michael. MF> On Fri, Jan 21, 2005 at 11:17:34AM +0500, Mihail Nasedkin wrote: >> I have already read about "System Columns" of the PostgreSQL documentation. >> In the table "pg_catalog.pg_attribute" column "attrelid" contain >> only "system OID's" but not OID's from records of the user tables. >> >> But I would like to use OID's of all records of the all my tables. >> ^^^ ^^^ MF> If you want to do that then you'll need to know which tables have MF> OIDs. If you just want rows then you could query pg_class and MF> filter on the relhasoids column, but if you also want things like MF> large objects then you might need to query pg_attribute and look MF> for all columns having an "oid" type. It sounds like you're not MF> interested in the latter, however. I don't need to know which tables have OIDS. I want know which system table contain column OID with all OID's inserted into my tables. Or is there system function that return last insert oid like $sth->{'pg_oid_status'} in the DBD::Pg? >> I try to use rules on INSERT action of my tables to store last insert >> oid, but at the moment of the INSERT row into table OID value >> inaccessible (unknown). MF> A row's OID should be visible in an AFTER trigger. OK. >> >> I would like use some SQL queries with the all OID's. >> >> MF> To what end? Are you aware that PostgreSQL allows tables to be >> MF> created without OIDs? >> >> Yes, of course, but in my case I create tables with OID and then want use >> OID of all records of the all tables as one column in some query. MF> Are you aware that OIDs aren't guaranteed to be unique due to MF> wraparound? If you have a UNIQUE constraint on each table's oid MF> column then the combination of (tableoid, oid) might serve your MF> needs. I think that OIDs are guaranteed to be unique according to FAQ 4.16) What is an OID? What is a TID? >> I think what system of OID's is very useful for application! MF> Assigning row IDs from a common sequence could serve the same MF> purpose, and since sequences are 64 bits you wouldn't be as subject MF> to a wraparound problem (OIDs are 32 bits). OIDs are stored as 4-byte integers (see FAQ) >> MF> What problem are you trying to solve? >> >> For example, I want to fetching all rows of the several tables in one >> query by means of LEFT JOIN, but not use UNION operator. MF> Again, what problem are you trying to solve? Using OIDs might not MF> be the best solution, and if we knew what you're trying to do then MF> we might be able to suggest alternatives. Why alternatives if already exists system of the identification of all rows from all tables. -- Regards, Mihail Nasedkin mailto:m.nasedkin.perm@mail.ru