Received: from golem.jpl.nasa.gov (root@hectic-1.jpl.nasa.gov [128.149.68.203]) by hub.org (8.8.8/8.7.5) with ESMTP id BAA14516 for ; Thu, 10 Sep 1998 01:54:07 -0400 (EDT) Received: from alumni.caltech.edu (localhost [127.0.0.1]) by golem.jpl.nasa.gov (8.8.5/8.8.5) with ESMTP id FAA21854; Thu, 10 Sep 1998 05:53:57 GMT Sender: tgl@mythos.jpl.nasa.gov Message-ID: <35F76975.50A9DF8C@alumni.caltech.edu> Date: Thu, 10 Sep 1998 05:53:57 +0000 From: "Thomas G. Lockhart" Organization: Caltech/JPL X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: Bruce Momjian CC: PostgreSQL-development Subject: Re: [HACKERS] open 6.4 items References: <199809100504.BAA20060@candle.pha.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > fix problem when DEFAULT string for CHAR() is not same as column I think I fixed that a while ago. I've forgotten which file was involved, but I no longer see the symptom on my system. > man pages/sgml synchronization (dump out man pages as postscript?) We should synchronize the man pages and sgml for this release, if possible, and then commit to using the sgml sources for man pages for v6.5. After v6.4 is released, man pages (but not sgml) are frozen until they can be generated from the sgml. > remove PARSEDEBUG defines if not longer needed OK. You really want those gone, don't you! > use index with constants on functions Not likely for v6.4. On my list for v6.5. > SELECT oid @ oid @ oid FROM pg_user fails with parser error, not > function error What is the issue with this? The parser doesn't know how to group the arguments and operators, so barfs. The only operators which have explicit precedence are the plain standard ones (+,-,*,/ for math and =,<,> for comparisons, and |,: for who-knows-what). Everything else falls into the same precedence, higher than the comparison operators and lower than the math ones. This includes, for example, "<=" which should be the same precedence as the other comparison ops, but has higher precedence at the moment. > no min/max for oid type Does this still need to be on the list? The guy who asked for it actually needed something else... - Tom