Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aEK5d-0002Ux-Sa for pgsql-sql@arkaria.postgresql.org; Wed, 30 Dec 2015 16:59:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aEK5d-0003Q1-7O for pgsql-sql@arkaria.postgresql.org; Wed, 30 Dec 2015 16:59:09 +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) (envelope-from ) id 1aEK4e-0002Jw-EV for pgsql-sql@postgresql.org; Wed, 30 Dec 2015 16:58:08 +0000 Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aEK4b-0008Ti-Be for pgsql-sql@postgresql.org; Wed, 30 Dec 2015 16:58:07 +0000 Received: by mail-wm0-x234.google.com with SMTP id f206so84559983wmf.0 for ; Wed, 30 Dec 2015 08:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=Enwa6xQh4x/OuQOiD8lPI+pswbgbYDFDLo9nC5RvWyE=; b=aoiJaG7+tZCbn4fCsa7Hp0jvEeNBjjnYw5JEKM4e6ypg4EMxGxQjqkNb7UU5WxSMyh p12fD0FVUqY9CH4Fo1rxQLPDMgw2Z+knnz0ovRbS2hBxy+AQvnqGlyNa1/WiOANSAqkD NYz3r+FHeCpv0JS2E9SygLdF/F4R96mzC5xstGR0zUlAjCtcyeIGmA/ZiN0fG57m+dRm PCE3Yym89S73oGNQbXxZhN96I1vH3Dx42EDmZje/uU+JBo1wtdyZ96jH1yruDjj+VsjJ vXDE5+zGs8ppjwADdCAyI15FRExQo6ZWtx0EkD8V3stCT6MAHoGEl2OJbdbLrRlZsNum z/LQ== X-Received: by 10.28.187.67 with SMTP id l64mr52905695wmf.39.1451494684180; Wed, 30 Dec 2015 08:58:04 -0800 (PST) Received: from timbomac.local (host86-147-73-225.range86-147.btcentralplus.com. [86.147.73.225]) by smtp.googlemail.com with ESMTPSA id w124sm58118087wmg.17.2015.12.30.08.58.03 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Dec 2015 08:58:03 -0800 (PST) To: pgsql-sql@postgresql.org From: Tim Dudgeon Subject: question on row level security Message-ID: <56840D1A.8030203@gmail.com> Date: Wed, 30 Dec 2015 16:58:02 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) 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 The new row level security feature in 9.5 looks great. I guess its designed around the need to restrict access based on the current database user (current_user) where this maps to a database user. But most applications now access the database using an application user and manages data for the applications multiple users (probably with each user being a row in a USERS table somewhere). Is there any way to "inject" the application user so that this can be used in a RLS check? e.g. conceptually: set app_user 'john'; select * from foo; where the select * is restricted by a RLS check that includes 'john' as the app_user. Of course custom SQL could be generated for this, but it would be safer if it could be handled using RLS. Any ways to do this? Tim -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql