> There are also some compatibility concerns involved. If we add
> grantable privileges for TRUNCATE and/or DDL operations, then GRANT ALL
> ON TABLE suddenly conveys a whole lot more privilege than it did before.
> This could lead to unpleasant surprises in security-sensitive
> operations. One c
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Simon Riggs wrote:
>> One fairly obvious difficulty is how to pass the trigger any meaningful
>> information about what happened (or is about to happen). In the case of
>> TRUNCATE, pretty much everything you need to know is implicit in the
>>
On Sat, 2008-02-02 at 17:38 -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Sat, Feb 02, 2008 at 05:23:39PM -0500, Christopher Browne wrote:
> >> I think it would be nice to be able to have more "trigger hooks"
> >> relating to DDL changes, but I also think that will repres
David Fetter <[EMAIL PROTECTED]> writes:
> On Sat, Feb 02, 2008 at 05:23:39PM -0500, Christopher Browne wrote:
>> I think it would be nice to be able to have more "trigger hooks"
>> relating to DDL changes, but I also think that will represent some
>> fundamentally more difficult problems being rai
On Sat, Feb 02, 2008 at 05:23:39PM -0500, Christopher Browne wrote:
> On Feb 2, 2008 2:43 PM, David Fetter <[EMAIL PROTECTED]> wrote:
> > It still involves DDL-like operations in the sense of changing
> > (for the duration of the query) trigger behavior.
>
> But that "change of trigger behavior" i
On Feb 2, 2008 2:43 PM, David Fetter <[EMAIL PROTECTED]> wrote:
> It still involves DDL-like operations in the sense of changing (for
> the duration of the query) trigger behavior.
But that "change of trigger behavior" is still more in the "DML" sense
than "DDL sense."
The point of TRUNCATE is th
On Sat, Feb 02, 2008 at 02:23:40PM -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Thu, Jan 31, 2008 at 10:22:42AM +, Gregory Stark wrote:
> >> There are plenty of DDL commands which modify data (CREATE INDEX,
> >> ATLER TABLE ALTER COLUMN TYPE). The defining characteri
David Fetter <[EMAIL PROTECTED]> writes:
> On Thu, Jan 31, 2008 at 10:22:42AM +, Gregory Stark wrote:
>> There are plenty of DDL commands which modify data (CREATE INDEX,
>> ATLER TABLE ALTER COLUMN TYPE). The defining characteristic of DDL
>> is not that it doesn't modify the data but that it
On Thu, Jan 31, 2008 at 10:22:42AM +, Gregory Stark wrote:
>
> "Decibel!" <[EMAIL PROTECTED]> writes:
>
> > CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah,
> > etc.
>
> Fwiw I would call CLUSTER DDL. Note that it does make a change
> that's visible in the table definition
On Thu, Jan 31, 2008 at 11:45:55AM +, Simon Riggs wrote:
> On Thu, 2008-01-31 at 10:22 +, Gregory Stark wrote:
> > "Decibel!" <[EMAIL PROTECTED]> writes:
> >
> > > CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
> >
> > Fwiw I would call CLUSTER DDL. Note that it d
On Thu, 2008-01-31 at 10:22 +, Gregory Stark wrote:
> "Decibel!" <[EMAIL PROTECTED]> writes:
>
> > CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
>
> Fwiw I would call CLUSTER DDL. Note that it does make a change that's visible
> in the table definition afterwards.
>
On Thu, 2008-01-31 at 10:22 +, Gregory Stark wrote:
> "Decibel!" <[EMAIL PROTECTED]> writes:
>
> > CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
>
> Fwiw I would call CLUSTER DDL. Note that it does make a change that's visible
> in the table definition afterwards.
"Decibel!" <[EMAIL PROTECTED]> writes:
> CLUSTER isn't DDL. Most forms of ALTER TABLE are. And CREATE blah, etc.
Fwiw I would call CLUSTER DDL. Note that it does make a change that's visible
in the table definition afterwards.
There are plenty of DDL commands which modify data (CREATE INDEX, AT
On Thu, 2008-01-31 at 01:12 -0600, Decibel! wrote:
> On Mon, Jan 28, 2008 at 09:09:13PM -0300, Alvaro Herrera wrote:
> > Decibel! wrote:
> > > On Fri, Jan 25, 2008 at 11:40:19AM +, Simon Riggs wrote:
> > > > (for 8.4 ...)
> > > > I'd like to introduce triggers that fire when we issue a truncate
On Mon, Jan 28, 2008 at 09:09:13PM -0300, Alvaro Herrera wrote:
> Decibel! wrote:
> > On Fri, Jan 25, 2008 at 11:40:19AM +, Simon Riggs wrote:
> > > (for 8.4 ...)
> > > I'd like to introduce triggers that fire when we issue a truncate:
> >
> > Rather than focusing exclusively on TRUNCATE, how
On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Notes: As the syntax shows, these would be statement-level triggers
> > (only). Requesting row level triggers will cause an error. [As Chris
> > Browne explained, if people really want, they can use the
Decibel! wrote:
> On Fri, Jan 25, 2008 at 11:40:19AM +, Simon Riggs wrote:
> > (for 8.4 ...)
> > I'd like to introduce triggers that fire when we issue a truncate:
>
> Rather than focusing exclusively on TRUNCATE, how about "triggers" that
> fire whenever any kind of DDL operation is performed
On Fri, Jan 25, 2008 at 11:40:19AM +, Simon Riggs wrote:
> (for 8.4 ...)
> I'd like to introduce triggers that fire when we issue a truncate:
Rather than focusing exclusively on TRUNCATE, how about "triggers" that
fire whenever any kind of DDL operation is performed? (Ok, truncate is
more DML
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > iirc, the suggestion was to exclude the non-SQL-spec things from 'GRANT
> > ALL' to avoid just that issue. Having to grant TRUNCATE and/or DDL
> > operation permissions explicitly would be reasonable. This might
On Sat, 2008-01-26 at 11:19 -0500, Robert Treat wrote:
> On Friday 25 January 2008 06:40, Simon Riggs wrote:
> > Notes: As the syntax shows, these would be statement-level triggers
> > (only). Requesting row level triggers will cause an error. [As Chris
> > Browne explained, if people really want,
Stephen Frost <[EMAIL PROTECTED]> writes:
> iirc, the suggestion was to exclude the non-SQL-spec things from 'GRANT
> ALL' to avoid just that issue. Having to grant TRUNCATE and/or DDL
> operation permissions explicitly would be reasonable. This might create
> a disconnect with what 'revoke all'
* Tom Lane ([EMAIL PROTECTED]) wrote:
> There are also some compatibility concerns involved. If we add
> grantable privileges for TRUNCATE and/or DDL operations, then GRANT ALL
> ON TABLE suddenly conveys a whole lot more privilege than it did before.
> This could lead to unpleasant surprises in s
Stephen Frost <[EMAIL PROTECTED]> writes:
> Of course, the last time this went around the argument was that we
> shouldn't add alot of extra code until we actually needed to, while at
> the same time we shouldn't use up the few remaining bits we have. The
> fact that this makes for an impossible s
Robert Treat <[EMAIL PROTECTED]> writes:
> This seems to completly hand-wave away the idea of implementing row level
> visibility in statement level triggers, something I am hoping to see
> implemented somewhere down the line. Am I missing something?
That was discussed already --- we agreed that
On Sat, Jan 26, 2008 at 04:33:53PM +, Gregory Stark wrote:
> "Robert Treat" <[EMAIL PROTECTED]> writes:
>
> > the idea of implementing row level visibility in statement level triggers
>
> Huh?
I think he means that statement level triggers can see the rows that
got affected, presumably by NE
Robert Treat wrote:
On Friday 25 January 2008 06:40, Simon Riggs wrote:
Notes: As the syntax shows, these would be statement-level triggers
(only). Requesting row level triggers will cause an error. [As Chris
Browne explained, if people really want, they can use these facilities
to create a B
"Robert Treat" <[EMAIL PROTECTED]> writes:
> the idea of implementing row level visibility in statement level triggers
Huh?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
---(end of broadc
On Friday 25 January 2008 06:40, Simon Riggs wrote:
> Notes: As the syntax shows, these would be statement-level triggers
> (only). Requesting row level triggers will cause an error. [As Chris
> Browne explained, if people really want, they can use these facilities
> to create a Before Statement tr
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> Perhaps we should be implementing "extended privileges" by using one
> additional bit to mean "has extended privilege list". We presumably want
> to implement column level privileges, plus you raise interesting
> thoughts about fine grained security access
On Jan 26, 2008 8:14 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> This two-faced personality is just why we're facing this problem. It looks to
> users like DML but it under the hood it behaves just like DDL.
>
Agreed that it looks like DML. Speaking as a user, I came away from
the documentatio
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2008-01-25 at 14:00 -0500, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
>> >> There are way too many table privilege bits already; to add more you
>> >> need something a lot st
On Fri, 2008-01-25 at 14:00 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> >> There are way too many table privilege bits already; to add more you
> >> need something a lot stronger than a "might be nice" argument.
>
> > Pe
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> >> There are way too many table privilege bits already; to add more you
> >> need something a lot stronger than a "might be nice" argument.
>
> > People use TRUN
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
>> There are way too many table privilege bits already; to add more you
>> need something a lot stronger than a "might be nice" argument.
> People use TRUNCATE whatever we say. If you force people to be ta
On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Notes: As the syntax shows, these would be statement-level triggers
> > (only). Requesting row level triggers will cause an error. [As Chris
> > Browne explained, if people really want, they can use the
Simon Riggs <[EMAIL PROTECTED]> writes:
> Notes: As the syntax shows, these would be statement-level triggers
> (only). Requesting row level triggers will cause an error. [As Chris
> Browne explained, if people really want, they can use these facilities
> to create a Before Statement trigger that e
(for 8.4 ...)
I'd like to introduce triggers that fire when we issue a truncate:
CREATE TRIGGER name [BEFORE | AFTER ] TRUNCATE ON table
FOR EACH STATEMENT EXECUTE PROCEDURE function (arguments);
The truncate trigger would fire separately from a statement-level DELETE
statement, to allow us to di
37 matches
Mail list logo
