On Wed, Jan 02, 2013 at 05:31:42PM +0000, Simon Riggs wrote: > On 2 January 2013 17:19, David Fetter <da...@fetter.org> wrote: > > > Would COPY be covered separately? How about TRUNCATE? > > COPY == INSERT
Makes sense. The reason I mentioned it is that COPY is supposed to be a very fast bulk loading process, which implies a couple of things: 1. In the RLS (really should be RLAC, but let's not go there now) case, COPY makes it pretty simple to probe hugely many things at once for existence unless there's some kind of COPY pre-processor that throws away non-matching rows. Fortunately there's work being done to that end. 2. COPY, being intended to be very, very fast, should probably get some kind of notation, at least in the docs, about how it will slow down in the RLS case. > TRUNCATE isn't covered at all since it doesn't look at rows. It has a > separate privilege that can be granted to those that need it. OK > > Also, is there any way to apply this to the catalog, or would that > > be too large a restructuring, given how catalog access actually > > works? > > Doubt it. Somewhat related issue: Is there a worked example of setting up PostgreSQL to a "default deny" access policy as far as is possible today? This touches a lot of things, among them reading the catalog. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers