* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > [ column privs cleanup patch ]
>
> Applied with revisions, as per previous messages.
Great, thanks!
Stephen
signature.asc
Description: Digital signature
Stephen Frost writes:
> [ column privs cleanup patch ]
Applied with revisions, as per previous messages.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On Tue, Feb 3, 2009 at 7:04 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> * Some of the information_schema views are specified to respond to
>>> per-column privileges; the column_privileges and columns views
>>> certainly need work now to meet spec, and
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> * Some of the information_schema views are specified to respond to
>> per-column privileges; the column_privileges and columns views
>> certainly need work now to meet spec, and there might be others.
> Done.
I looked through the
Tom, all,
In the attached patch-
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> * Some of the information_schema views are specified to respond to
> per-column privileges; the column_privileges and columns views
> certainly need work now to meet spec, and there might be others.
Done.
> * It might be
Tom, et al,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> There are still some significant loose ends though:
Apologies for not having this finished already, been kind of caught up
in some discussions. :)
> * Some of the information_schema views are specified to respond to
> per-column privileges; th
On Thu, Jan 22, 2009 at 07:03:45PM -0500, Tom Lane wrote:
> BTW, something else I'd meant to bring up for discussion is whether
> anyone likes the formatting of column privileges in \dp:
>
> regression=# create table foo(bar int, baz int);
> CREATE TABLE
> regression=# grant select on foo to joe;
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, the examples I've looked at fit in 80 columns, but it's true that
> all the identifiers involved were pretty short. The alternative I think
> you're suggesting is
Yeah, I see that now. I guess you'd need a column identifier wider than
'Column Access
Stephen Frost writes:
> One thing that just occured to me is that we could, should we want to,
> move the column-level privs over into the 'Access privileges' column by
> just adding them on after the table-level privs. We would want to make
> sure the table-level privs come first and maybe have
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> BTW, something else I'd meant to bring up for discussion is whether
> anyone likes the formatting of column privileges in \dp:
Well, I kinda like it, but that's not an entirely unbiased opinion. ;)
> Access privileges
> Schem
BTW, something else I'd meant to bring up for discussion is whether
anyone likes the formatting of column privileges in \dp:
regression=# create table foo(bar int, baz int);
CREATE TABLE
regression=# grant select on foo to joe;
GRANT
regression=# grant insert(bar), update(baz) on foo to joe;
GRANT
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Applied with revisions. The main externally visible change is that I
> implemented per-column REFERENCES privilege, since that's required by
> spec. I did some heavy revision of the parsing support too, as per
> previous dicussions, and editorial cleanup a
On Thu, Jan 22, 2009 at 3:29 PM, Tom Lane wrote:
>
> * We probably ought to invent has_column_privilege SQL functions
> analogous to has_table_privilege; this is not just for completeness,
> but is probably necessary to finish the above items.
>
+1
> * ISTM that COPY with a column list should su
Stephen Frost writes:
> Attached is an updated patch for column-level privileges.
Applied with revisions. The main externally visible change is that I
implemented per-column REFERENCES privilege, since that's required by
spec. I did some heavy revision of the parsing support too, as per
previ
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> On looking closer, though, it's *still* messy and unobvious :-(.
>> There is no single place in the parser where we have the complete
>> multi-level query tree available in a convenient form for this sort of
>> postprocessing.
>
> Th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> On looking closer, though, it's *still* messy and unobvious :-(.
> There is no single place in the parser where we have the complete
> multi-level query tree available in a convenient form for this sort of
> postprocessing.
That's unfortunate. :/
> I've th
KaiGai Kohei writes:
> Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> On the whole I think we have to go back to the original plan of
>>> recursively searching the query's expressions after we've finished all
>>> the transformations (and have a completed jointree to refer to).
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> On the whole I think we have to go back to the original plan of
>> recursively searching the query's expressions after we've finished all
>> the transformations (and have a completed jointree to refer to). This
>> is slightly annoyin
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... btw, what is the reasoning behind the special cases for SELECT FOR
> UPDATE in execMain.c?
Basically, because the original logic allowed SELECT-FOR-UPDATE if you
only had SELECT rights, which wasn't right.
> If there actually is a need to treat SELECT
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> On the whole I think we have to go back to the original plan of
> recursively searching the query's expressions after we've finished all
> the transformations (and have a completed jointree to refer to). This
> is slightly annoying on the grounds of adding
... btw, what is the reasoning behind the special cases for SELECT FOR
UPDATE in execMain.c?
/* Check if this is SELECT-FOR-UPDATE and handle
* accordingly. */
if(remainingPerms & ACL_UPDATE &&
pg_attribute_ac
Stephen Frost writes:
> Attached is an updated patch for column-level privileges.
I'm working on getting this committed. I've run into a major stumbling
block in the parse-time marking of columns for SELECT privileges: the
do-it-as-the-Vars-get-transformed approach basically doesn't work as-is
Jaime Casanova wrote:
On Tue, Apr 1, 2008 at 5:40 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Apologies if this gets duplicated - original seems to have been dropped due
to patch size - this time I am sending it gzipped.
just for the record, this patch doesn't apply cleanly to CVS
On Tue, Apr 1, 2008 at 5:40 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> Apologies if this gets duplicated - original seems to have been dropped due
> to patch size - this time I am sending it gzipped.
>
just for the record, this patch doesn't apply cleanly to CVS
--
regards,
Jaime Casanova
as patch before 8.4 release.
Sanjay Sharma
> Date: Tue, 1 Apr 2008 22:02:30 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] column level privileges
>
>
>
> The earliest will be 8.4, which is many many
gsql-hackers@postgresql.org> Subject: Re: [HACKERS]
column level privileges> > > > The earliest will be 8.4, which is many many
months away.> > It should be possible to produce a patch for 8.3 if you're
interested.> > cheers> > andrew> > sanjay sharma wrote
The earliest will be 8.4, which is many many months away.
It should be possible to produce a patch for 8.3 if you're interested.
cheers
andrew
sanjay sharma wrote:
Hello Andrew,
When do you expect this patch to go in production and available for
public use? I would keep an eye for its re
Hello Andrew,
When do you expect this patch to go in production and available for public use?
I would keep an eye for its release.
Sanjay Sharma> Date: Tue, 1 Apr 2008 18:40:24 -0400> From: [EMAIL PROTECTED]>
To: pgsql-hackers@postgresql.org> Subject: [HACKERS] column level privileges> >
>
28 matches
Mail list logo
