X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 58101529BF; Wed, 6 Jul 2005 22:21:15 -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 28533-09; Thu, 7 Jul 2005 01:21:12 +0000 (GMT) Received: from houston.familyhealth.com.au (houston.au.fhnetwork.com [203.22.197.21]) by svr1.postgresql.org (Postfix) with ESMTP id A37A252835; Wed, 6 Jul 2005 22:21:08 -0300 (ADT) Received: from houston.familyhealth.com.au (localhost [127.0.0.1]) by houston.familyhealth.com.au (Postfix) with ESMTP id 779A824FDD; Thu, 7 Jul 2005 09:21:06 +0800 (WST) Received: from [127.0.0.1] (work-40.internal [192.168.0.40]) by houston.familyhealth.com.au (Postfix) with ESMTP id 5F52524FCE; Thu, 7 Jul 2005 09:21:06 +0800 (WST) Message-ID: <42CC840E.3030708@familyhealth.com.au> Date: Thu, 07 Jul 2005 09:23:26 +0800 From: Christopher Kings-Lynne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Robert Perry , pgsql-interfaces@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] By Passed Domain Constraints References: <61C4410A-F2CE-49E9-92BA-1BDF89818DAA@lodestonetechnologies.com> <26103.1120660537@sss.pgh.pa.us> <27039.1120665958@sss.pgh.pa.us> In-Reply-To: <27039.1120665958@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.063 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200507/13 X-Sequence-Number: 5649 > You could work around this by explicitly specifying the parameter > type as text or varchar or whatever the domain's base type is. > I wonder though if we oughtn't change the backend so that the inferred > type of a parameter symbol is never a domain, but the domain's base > type. That would force the proper application of CoerceToDomain inside > the constructed query parsetree. Remember we have similar weirdness when returning domain types from stored procs :( Chris