Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLZ8G-0001d0-3b for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Dec 2016 17:32:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cLZ8F-0005JF-ER for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Dec 2016 17:32:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cLZ8D-0005Iw-Hx for pgsql-hackers@postgresql.org; Mon, 26 Dec 2016 17:32:17 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cLZ86-000193-Qq for pgsql-hackers@postgresql.org; Mon, 26 Dec 2016 17:32:17 +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 uBQHW7d2007097; Mon, 26 Dec 2016 12:32:07 -0500 From: Tom Lane To: Michael Paquier cc: Joe Conway , PostgreSQL mailing lists Subject: Re: Incautious handling of overlength identifiers In-reply-to: <6481.1482771955@sss.pgh.pa.us> References: <17691.1482523168@sss.pgh.pa.us> <20641.1482525852@sss.pgh.pa.us> <6481.1482771955@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 26 Dec 2016 12:05:55 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7095.1482773527.1@sss.pgh.pa.us> Date: Mon, 26 Dec 2016 12:32:07 -0500 Message-ID: <7096.1482773527@sss.pgh.pa.us> X-Pg-Spam-Score: -5.0 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org I wrote: > Another idea worth considering is to just make the low-level functions > do truncation ... After further thought, there's a bigger-picture issue here, which is whether the inputs to the SQL functions in question are intended to be raw user input --- in which case, not only would truncation be an appropriate service, but probably so would downcasing --- or whether they are more likely to be coming from a catalog scan, in which case you don't want any of that stuff. Nobody's going to be happy if we start making them add quote_ident() around references to name columns. I think the privilege-inquiry functions are almost certainly mostly used in the latter style; there might be more room for debate about, say, pg_get_serial_sequence. Since the low-level functions need to support both use cases, asking them to handle truncation is wrong, just as much as it would be to ask them to do downcasing. If we take these SQL functions as being meant for use with inputs coming from catalogs, then they don't need to do truncation for user-friendliness purposes; it's perfectly fine to treat overlength inputs as "name not found" cases. So that says we could just remove that Assert and decide we're done. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers