Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA80309 for ; Thu, 15 Jul 1999 02:15:11 -0400 (EDT) (envelope-from lockhart@alumni.caltech.edu) Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1]) by localhost (8.8.7/8.8.7) with ESMTP id GAA31972; Thu, 15 Jul 1999 06:15:16 GMT Sender: lockhart@hub.org Message-ID: <378D7C74.99700FF7@alumni.caltech.edu> Date: Thu, 15 Jul 1999 06:15:16 +0000 From: Thomas Lockhart X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: Hiroshi Inoue CC: Tom Lane , Constantin Teodorescu , Bruce Momjian , Hannu Krosing , pgsql-hackers@postgreSQL.org Subject: Re: [HACKERS] Interesting behaviour ! References: <000a01bece58$7dd97600$2801007e@cadzone.tpf.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Each type has a typeinput(char * => type ) proc and a typeoutput( > type -> char *) proc. > Doesn't int2in(int4out()) convert int4 to int2 ? > However,typeinput proc causes elog(ERROR) in most cases if it > couldn't convert correctly. Conversion using an intermediate string is possible, but not the preferred technique. The "automatic type coersion" code, used earlier in the parser, uses the convention that any single-argument function taking the source type as input and with the same name as the target type can be used for type conversion. For example, the function int4(int2) would convert int2 to int4. There are now routines in the parser for choosing conversion strategies and for finding candidates, and these could be reused for similar purposes when trying to match index arguments. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California