Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
> > with GRANT/REVOKE. Peter, Tom, how is GRANT/REVOKE different?
>
> GRANT/REVOKE behavior is specified by the standard, whereas the stuff
> we allow under ALTER V
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> >>> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
> >>
> >> The SQL standard doesn't specify it. And there is no need for
Robert Haas wrote:
> >> While we don't _need_ it, it would make our system more consistent; we
> >> have made similar changes for views in other areas.
> >
> > I'm not sure it'd make the system more consistent. Because the SQL
> > standard says you use GRANT ON TABLE for a view. we'd have to alwa
>> While we don't _need_ it, it would make our system more consistent; we
>> have made similar changes for views in other areas.
>
> I'm not sure it'd make the system more consistent. Because the SQL
> standard says you use GRANT ON TABLE for a view. we'd have to always
> ensure that we accepted
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
> with GRANT/REVOKE. Peter, Tom, how is GRANT/REVOKE different?
GRANT/REVOKE behavior is specified by the standard, whereas the stuff
we allow under ALTER VIEW is all an extension to t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
>>> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
>>
>> The SQL standard doesn't specify it. And there is no need for it.
> While we don't _need_
Peter Eisentraut wrote:
> On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> > Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
>
> The SQL standard doesn't specify it. And there is no need for it.
While we don't _need_ it, it would make our system more consistent; w
On Tuesday 01 July 2008 01:39:13 Bruce Momjian wrote:
> Is there a downside to adding "VIEW" in parser/gram.y:privilege_target?
The SQL standard doesn't specify it. And there is no need for it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Fri, 2008-08-22 at 12:42 -0400, Andrew Dunstan wrote:
> depends if you think hacking the bison grammar is a beginner task.
It may be anything from beginners task to quite complex . Some things
are just copy&paste.
-
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
depends if you think hacking the bison grammar is a beginner task.
cheers
andrew
Decibel! wrote:
Are we still tracking beginner TODOs separately? I'm thinking this
falls into that category...
Barring objection, I'll mark it as easy.
On Aug 21, 2008, at 5:38 PM, Bruce Momjian wrote:
Adde
Decibel! wrote:
> Are we still tracking beginner TODOs separately? I'm thinking this
> falls into that category...
>
> Barring objection, I'll mark it as easy.
I already had; markers just don't cust/paste easily like they used to.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.
Are we still tracking beginner TODOs separately? I'm thinking this
falls into that category...
Barring objection, I'll mark it as easy.
On Aug 21, 2008, at 5:38 PM, Bruce Momjian wrote:
Added to TODO:
Allow GRANT/REVOKE on views to use the VIEW keyword rather
than just TABL
Added to TODO:
Allow GRANT/REVOKE on views to use the VIEW keyword rather
than just TABLE
http://archives.postgresql.org/pgsql-hackers/2008-06/msg01133.php
---
Bruce Momjian wrote:
> Marc Munro wr
Marc Munro wrote:
-- Start of PGP signed section.
> The statement:
>
> revoke all on view internal.all_objects from public;
>
> yields a syntax error. The docs show that the word "view" is not
> acceptable in this statement which is fine but the surprising thing is
> that:
>
> ? revoke all o
14 matches
Mail list logo
