* 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
All,
Attached is an updated patch for column-level privileges. This is a
very minor change to use get_rel_name(), so the main point of this is
to update the general community on the status of the patch. It was
pointed out to me that some folks havn't been able to follow along and
so ar
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
r 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
>
>
> Apologies if this gets duplicated - original seems to have been dropped
> due to patch siz
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 leve
Apologies if this gets duplicated - original seems to have been dropped
due to patch size - this time I am sending it gzipped.
cheers
andrew
Original Message
Subject:column level privileges
Date: Tue, 01 Apr 2008 08:32:25 -0400
From: Andrew Dunstan <[EMAIL PROTE
30 matches
Mail list logo
