X-Original-To: pgsql-novice-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id BAF0132A221 for ; Fri, 1 Oct 2004 19:49:40 +0100 (BST) 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 81392-04 for ; Fri, 1 Oct 2004 18:49:38 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 356B132A21C for ; Fri, 1 Oct 2004 19:49:39 +0100 (BST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id i91InYXu013493; Fri, 1 Oct 2004 14:49:34 -0400 (EDT) To: Bruno Wolff III Cc: "D. Duccini" , pgsql-sql@postgresql.org, Pgsql-novice Subject: Re: [SQL] date_trunc'd timestamp index possible? In-reply-to: <20041001182830.GA20624@wolff.to> References: <20041001182830.GA20624@wolff.to> Comments: In-reply-to Bruno Wolff III message dated "Fri, 01 Oct 2004 13:28:30 -0500" Date: Fri, 01 Oct 2004 14:49:34 -0400 Message-ID: <13492.1096656574@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200410/10 X-Sequence-Number: 11095 Bruno Wolff III writes: > I am not sure how to check if the supplied function for converting > a timestamp with time zone to a timestamp without timezone using a > specified time zone is immutable. I think this function should be > immutable, but that it probably isn't. Yup. In 7.4: regression=# select provolatile from pg_proc where oid = 'timezone(text,timestamptz)'::regprocedure; provolatile ------------- s (1 row) regression=# This is a thinko that's already been corrected for 8.0: regression=# select provolatile from pg_proc where oid = 'timezone(text,timestamptz)'::regprocedure; provolatile ------------- i (1 row) regression=# If you wanted you could just UPDATE pg_proc to correct this mistake. Another possibility is to create a function that's an IMMUTABLE wrapper around the standard function. Looking at this, I realize that date_trunc() is mismarked: the timestamptz variant is strongly dependent on the timezone setting and so should be STABLE not IMMUTABLE. Ooops. regards, tom lane