pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Craig Ringer <craig@2ndquadrant.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Gregory Smith <gregsmithpgsql@gmail.com>
Cc: Greg Stark <stark@mit.edu>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Infinite recursion in row-security based on updatable s.b. views
Date: Tue, 28 Jan 2014 18:27:40 +0800
Message-ID: <52E7861C.9040402@2ndquadrant.com> (raw)
In-Reply-To: <52E76CD6.1010704@2ndquadrant.com>
References: <CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com>
	<1398.1378305956@sss.pgh.pa.us>
	<CA+TgmoYTf+4RUOW8stVz1RE+3TD+QR5TNKzYuFDCehSkieL5OQ@mail.gmail.com>
	<1543.1378306249@sss.pgh.pa.us>
	<2620.1378308159@sss.pgh.pa.us>
	<52775604.9090306@2ndquadrant.com>
	<11101.1383575839@sss.pgh.pa.us>
	<CA+TgmoZS46fGTHCMo1FpNiBYDU7Wrx7R8PL+48Xc7UcVCsuaUA@mail.gmail.com>
	<52784DF9.9040205@2ndquadrant.com>
	<CA+TgmobvM9t8y6+BoG0DXMVA5jcNc9V6fzNt2tNSaVqsRmGpHA@mail.gmail.com>
	<5279E3CA.7050400@2ndquadrant.com>
	<CAM-w4HOJaWt2naKakW67KRZE9mBcEF-BQ3UA=7SHKcFv3=FmVQ@mail.gmail.com>
	<527C478D.4070901@2ndquadrant.com>
	<52ABCF6C.4010409@gmail.com>
	<52ABE150.6050201@2ndquadrant.com>
	<52D98436.2030508@gmail.com>
	<52DC82E2.5010801@2ndquadrant.com>
	<52DCBEF1.3010004@2ndquadrant.com>
	<52E1CC04.8040907@2ndquadrant.com>
	<52E1DAD8.30909@2ndquadrant.com>
	<52E22C8E.2020702@2ndquadrant.com>
	<CAEZATCVJPnUrLjsS626Pp+r_bdq-3ofRHWmV0fKx1OgpyLt5ww@mail.gmail.com>
	<52E76CD6.1010704@2ndquadran! t.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 01/28/2014 04:39 PM, Craig Ringer wrote:
> I'm looking for where I found the code that already does this so I can
> point and say "I'm not crazy, we already do it here". Will follow up
> with a patch.

I spoke to soon. The code I'm talking about is
expand_inherited_tables(...) and it still uses rt_fetch, it just avoids
foreach(...) in favour of stopping scanning at the end of the original
rtable.

So I get to be crazy after all.

I really don't like how many places we're rt_fetch'ing the same RTE from
in updatable s.b. views and its interaction with row-security, but that
can be a "later" problem. For now I'll stick with RTIs.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (6+ messages)  latest in thread

Message-ID: <52E7861C.9040402@2ndquadrant.com>
Permalink:  ../52E7861C.9040402@2ndquadrant.com/
Also on:    postgresql.org/message-id/52E7861C.9040402@2ndquadrant.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: craig@2ndquadrant.com, dean.a.rasheed@gmail.com, gregsmithpgsql@gmail.com, stark@mit.edu, kaigai@kaigai.gr.jp
  Subject: Re: Infinite recursion in row-security based on updatable s.b. views
  In-Reply-To: <52E7861C.9040402@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox