Return-Path: pg_adm@postgres.berkeley.edu Received: by postgres.Berkeley.EDU (5.61/1.29) id AA27158; Tue, 17 Nov 92 09:47:07 -0800 Date: Tue, 17 Nov 92 09:47:07 -0800 Message-Id: <9211171747.AA27158@postgres.Berkeley.EDU> From: sbyates@phoenix.Princeton.EDU (Stanley B. Yates) Subject: value of relowner attribute in pg_class relation To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu I sent this in as a bug report some time ago, but received no reply. In the relation pg_class, the attribute relowner is supposed to be of type USER oid. In fact, it is the user's system id (UNIX uid) as can be seen from the following two retrieves on pg_user and pg_class. This makes it difficult to retrieve relations belonging to a given user since the system expects relowner to be of type oid yet the value is not, in fact, the oid. See the two queries which follow the tables. A related question: As you can see from table 2, all the relations are owned by postgres or sbyates (user id 4045). This is as expected. But two different system ids are used for postgres--the old number 6 (as required in earlier versions) and new tables created with version 4.0.1, which have the correct system id (6264) for the postgres account on our system. (Curriously, it's also the oid for the postgres user). Isn't this also a problem? Thanks, Stan Result no. oid usename usesysid -------- -------- -------- -------- 1 6264 postgres 6264 2 19680 sbyates 4045 3 19712 picasso 6879 4 115648 vince 6309 5 75680 tobypaff 844 6 115712 perry 73 7 125312 tengi 1519 Result no. oid relname relowner -------- -------- -------- -------- 1 53696 records 4045 2 88 pg_database 6 3 76 pg_demon 6 4 82 pg_server 6 5 86 pg_user 6 6 83 pg_class 6 7 80 pg_magic 6 8 89 pg_defaults 6 9 90 pg_variable 6 10 99 pg_log 6 11 100 pg_time 6 12 16600 pg_inherits 6264 13 16617 pg_index 6264 14 16638 pg_version 6264 15 16655 pg_statistic6264 16 16674 pg_operator 6264 17 16704 pg_opclass 6264 18 16719 pg_am 6264 19 16755 pg_amop 6264 20 16921 pg_amproc 6264 21 16961 pg_language 6264 22 16977 pg_parg 6264 23 17047 pg_aggregate6264 24 17086 pg_ipl 6264 25 17103 pg_inheritproc6264 26 17121 pg_platter 6264 27 17137 pg_plmap 6264 28 17157 pg_prs2rule 6264 29 17178 pg_prs2plans6264 30 17195 pg_prs2stub 6264 31 17213 pg_rewrite 6264 32 17236 pg_listener 6264 33 17253 pg_naming 6264 34 17270 pg_large_object6264 35 17287 pg_attnameind6264 36 75 pg_attribute6 37 17903 pg_attnumind6264 38 18518 pg_procidind6264 39 81 pg_proc 6 40 18932 pg_procnameind6264 41 19346 pg_typeidind6264 42 71 pg_type 6 43 19448 pg_typenameind6264 44 88960 images 4045 45 53742 name 4045 46 72015 nameind 4045 47 53791 subject 4045 48 72667 subjind 4045 49 68480 title 4045 50 73595 titleind 4045 51 75232 person 6264 52 75281 emp 6264 53 71008 recind 4045 54 75338 student 6264 55 75392 stud_emp 6264 56 75464 city 6264 Query sent to backend is "retrieve(r.relname)from r in pg_class, u in pg_user where r.relowner=u.oid and u.usename="sbyates" " --------------- | relname | --------------- Query sent to backend is "retrieve(r.relname)from r in pg_class, u in pg_user where r.relowner=u.usesysid and u.usename="sbyates"" NOTICE:Nov 17 11:17:51:there is no operator = for types oid and int2 NOTICE:Nov 17 11:17:51:You will either have to retype this query using an NOTICE:Nov 17 11:17:51:explicit cast, or you will have to define the operator WARN:Nov 17 11:17:51:= for oid and int2 using DEFINE OPERATOR