X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 5B9E232B6E4 for ; Sat, 2 Oct 2004 20:32:08 +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 46238-03 for ; Sat, 2 Oct 2004 19:32:01 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 88B4832AF45 for ; Sat, 2 Oct 2004 19:22:58 +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 i92IMo2C022071; Sat, 2 Oct 2004 14:22:50 -0400 (EDT) To: Peter Eisentraut Cc: Bruno Wolff III , pgsql-hackers@postgreSQL.org Subject: Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd timestamp index possible?) In-reply-to: <200410021941.30084.peter_e@gmx.net> References: <13492.1096656574@sss.pgh.pa.us> <15677.1096671183@sss.pgh.pa.us> <200410021941.30084.peter_e@gmx.net> Comments: In-reply-to Peter Eisentraut message dated "Sat, 02 Oct 2004 19:41:29 +0200" Date: Sat, 02 Oct 2004 14:22:50 -0400 Message-ID: <22070.1096741370@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/41 X-Sequence-Number: 59544 Peter Eisentraut writes: > Tom Lane wrote: >> What I'm inclined to do with these is change pg_proc.h but not force >> an initdb. Does anyone want to argue for an initdb to force it to be >> fixed in 8.0? We've lived with the wrong labelings for some time now >> without noticing, so it doesn't seem like a serious enough bug to >> force a post-beta initdb ... to me anyway. > I'd prefer if all users of 8.0 were guaranteed to have the same catalog. Well, there's something to be said for that viewpoint too. Anyone else feel the same? If we do go for an initdb, I'd like at the same time to do something I had intended to do but forgotten, which is to yank the functions and operators for basic arithmetic on type "char", and instead put in (explicit) conversions between "char" and integer. See for instance http://archives.postgresql.org/pgsql-sql/2002-11/msg00116.php http://archives.postgresql.org/pgsql-general/2004-08/msg01562.php http://archives.postgresql.org/pgsql-general/2004-09/msg01209.php Specifically I want to remove these operators: oid | oid | oprresult -----+-------------------+----------- 635 | +("char","char") | "char" 636 | -("char","char") | "char" 637 | *("char","char") | "char" 638 | /("char","char") | "char" and their underlying functions: oid | oid | prorettype | prosrc ------+--------------------------+------------+------------- 1248 | charpl("char","char") | "char" | charpl 1250 | charmi("char","char") | "char" | charmi 77 | charmul("char","char") | "char" | charmul 78 | chardiv("char","char") | "char" | chardiv The following operators on "char" will remain: oid | oid | oprresult -----+-------------------+----------- 92 | =("char","char") | boolean 630 | <>("char","char") | boolean 631 | <("char","char") | boolean 632 | <=("char","char") | boolean 633 | >("char","char") | boolean 634 | >=("char","char") | boolean These are not as dangerous as the arithmetic operators, because in a situation where the parser is having difficulty resolving types, it will prefer the "text" comparison operators over these. The reason the "char" arithmetic operators are dangerous is that they are the only ones of those names in the STRING type category. regards, tom lane