Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ayij2-0004XN-7W for pgsql-sql@arkaria.postgresql.org; Fri, 06 May 2016 16:35:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ayij1-0006VN-9q for pgsql-sql@arkaria.postgresql.org; Fri, 06 May 2016 16:35:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ayij0-0006TS-Fi for pgsql-sql@postgresql.org; Fri, 06 May 2016 16:35:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ayiit-00068L-VB for pgsql-sql@postgresql.org; Fri, 06 May 2016 16:35:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u46GZOX9005723; Fri, 6 May 2016 12:35:24 -0400 From: Tom Lane To: "David G. Johnston" cc: Adrian Klaver , Michael Moore , postgres list Subject: Re: weird error message In-reply-to: References: Comments: In-reply-to "David G. Johnston" message dated "Fri, 06 May 2016 08:22:05 -0700" Date: Fri, 06 May 2016 12:35:24 -0400 Message-ID: <5722.1462552524@sss.pgh.pa.us> X-Pg-Spam-Score: -4.0 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org "David G. Johnston" writes: > I don't know that this is covered all that well in the documentation. It'd be better to do something about it than document it. The core of the problem is that if we don't resolve the type of an unknown literal while processing the sub-SELECT's target list, it doesn't work to try to make a conversion later. I think there's a rough consensus that it'd be okay to resolve unknown to text at the time that the subquery is parsed, if there's no reason to resolve it to something else. There would be cases where that's not really what you want, but it would be unsurprising for it to act that way. The hard part is that we've historically allowed INSERT INTO sometab SELECT 'foo', ... to resolve 'foo' as the type of sometab's first column (and I think this is required by SQL spec, actually). So some work would have to be done to not break that behavior. But I think this could be managed by explicitly passing down knowledge of the INSERT's target column types into the parsing of the sub-SELECT, and then the rule could be "resolve an unknown SELECT output column to whatever target type is provided by context, or to TEXT if the context provides no target". regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql