Re: [HACKERS] Permissions on copy - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Permissions on copy
Date
Msg-id 199802201703.MAA05866@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Permissions on copy  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: [HACKERS] Permissions on copy  (The Hermit Hacker <scrappy@hub.org>)
List pgsql-hackers
>
> On Fri, 20 Feb 1998, Bruce Momjian wrote:
>
> > >
> > > Since the copy statement is behaving differently than the normal select
> > > stuff,
> > > I think we should eighter introduce a new permission (name it copy or dump)
> > > or include the copy into the rewrite system.
> > >
> > > I would vote for the first and implement a new command:
> > >     unload to <filename> [delimiter '|'] <select statement>;    -- and
> > >     load from <filename> [delimiter '|'] <insert statement>;
> > > that does behave like the select.      (please forgive my Informix
> > > background)
> >
> > Yes, I agree the Informix way of having load/unload, and having a SELECT
> > capability so you can dump any data/join you want, not just a single
> > table.  Do I have votes to put this on the TODO list?
>
>     I'm not quite sure what we are voting on here...is it to implement
> permissions on a copy, like we do on 'select/delete/insert/etc'?
>
>     If so, count me in...

Two things.  First was a separate COPY priviledge, which I vote against.
I see no real value to it, except to work around the problem that COPY
doesn't use rules.

Second, there was the idea of making copy allow a real select statement
and not just a table name.  If we do that, all goes through the
executor, and you get view and rules working properly.  May have some
performance penalty, though it probabably will be minor.

--
Bruce Momjian
maillist@candle.pha.pa.us

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Who is everyone?
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Subselects and NOTs