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 1053FD1B17C for ; Thu, 10 Jun 2004 10:20:53 -0300 (ADT) 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 19262-02 for ; Thu, 10 Jun 2004 13:20:52 +0000 (GMT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by svr1.postgresql.org (Postfix) with SMTP id 4129CD1B17B for ; Thu, 10 Jun 2004 10:20:46 -0300 (ADT) Message-ID: <20040610132050.94570.qmail@web13801.mail.yahoo.com> Received: from [216.173.173.66] by web13801.mail.yahoo.com via HTTP; Thu, 10 Jun 2004 06:20:50 PDT Date: Thu, 10 Jun 2004 06:20:50 -0700 (PDT) From: Chris Gamache Reply-To: cgg007@yahoo.com Subject: Re: Schema + User-Defined Data Type Indexing problems... To: Tom Lane Cc: pgsql-sql@postgresql.org In-Reply-To: <19454.1086841261@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.9 tagged_above=0.0 required=5.0 tests=FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR X-Spam-Level: * X-Archive-Number: 200406/81 X-Sequence-Number: 18026 --- Tom Lane wrote: > Chris Gamache writes: > > I'm having a heck of a time, and it seems like in my thrashing about > > to find a solution to this problem I have ruined the uniqueidentifier > > datatype in the schema... > > > CREATE INDEX mt_uuid_idx > > ON my_schema.my_table USING btree (my_uuid); > > > ERROR: data type my_schema.uniqueidentifier has no default operator class > for > > access method "btree" > > HINT: You must specify an operator class for the index or define a default > > operator class for the data type. > > > I can look at the operator classes and see that there is an operator class > for > > btree for my_schema.uniqueidentifier. > > IIRC, the opclass has to be in a schema that is in your schema search > path to be found by CREATE INDEX by default. If it isn't, you could > specify it explicitly: > > CREATE INDEX mt_uuid_idx > ON my_schema.my_table USING btree (my_uuid USING my_schema.uuidopclass); > > It's possible that we could think of a more convenient behavior for > default opclasses, but I don't want to do something that would foreclose > having similarly-named datatypes in different schemas. You have any > suggestions? That /is/ important to be able to have similarly named datatypes in different schemas. I'll give the explicit opclass a go. Indeed, if I place the schema in my search path the index creation and index scans seem to work perfectly. I had wanted to have to specify the schema whenever I referenced objects in it instead of putting it in my search path. I had no concept of exactly how truly separated schemas are. The only idea that I can think of (and, again, I may be underestimating the level of separation that needs to exist between schema) is that object creation could implicitly looks to the current schema for a usable index/opclass/whatever first before checking the search path. A SELECT could look first to the schema of the table before checking the search path for a usable index. Is it even possible to create an index that lives in a different schema from the table it is indexing? CG __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/