Patch applied. Thanks.
---
Gavin Sherry wrote:
> Attached is a patch adding regression tests for this code.
>
> Thanks,
>
> Gavin
>
> On Tue, 23 Aug 2005, Bruce Momjian wrote:
>
> >
> > Thanks, modified patch applied b
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ga
Attached is a patch adding regression tests for this code.
Thanks,
Gavin
On Tue, 23 Aug 2005, Bruce Momjian wrote:
>
> Thanks, modified patch applied by Tom, with the addition of a USER
> triggers only mode.
>
> ---
>
> Sat
Thanks, modified patch applied by Tom, with the addition of a USER
triggers only mode.
---
Satoshi Nagayasu wrote:
> The message format for elog() report is cleaned up.
>
> --
> NAGAYASU Satoshi <[EMAIL PROTECTED]>
> diff
The message format for elog() report is cleaned up.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
diff -cr pgsql.orig/src/backend/commands/tablecmds.c
pgsql/src/backend/commands/tablecmds.c
*** pgsql.orig/src/backend/commands/tablecmds.c 2005-06-28 14:08:54.0
+0900
--- pgsql/src/backend/comma
> This isn't really a gain in localizability because it assumes that there
> are only singular and plural forms. I do agree that plugging words like
> "enabled" or "disabled" into a string is not good style. Please read
> the message style guidelines at
> http://developer.postgresql.org/docs/pos
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> What does "really be two messages" mean?
> I mean you should do this:
> if (enabled)
> {
> if (changed == 1)
> ereport("One trigger on %s enabled")
> else
> ereport("%d triggers on %d enabled")
> }
This isn't r
On Mon, Aug 08, 2005 at 02:13:28PM +0900, Satoshi Nagayasu wrote:
> Alvaro Herrera wrote:
> >>+ elog(NOTICE, "%d trigger(s) on %s %s.",
> >>+changed,
> >>+NameStr(rel->rd_rel->relname),
> >>+enable ? "enabled" : "disabled");
> >
> >
> > should really be two
Alvaro Herrera wrote:
> There are a few elog() calls that should really be ereport(). Also
> this message
I've fixed to call ereport() on permission error.
>>+ elog(NOTICE, "%d trigger(s) on %s %s.",
>>+ changed,
>>+ NameStr(rel->rd_rel->relname),
>>+ e
On Mon, Aug 08, 2005 at 08:07:05AM +0900, Satoshi Nagayasu wrote:
> Here is new patch with pg_dump modification.
There are a few elog() calls that should really be ereport(). Also
this message
> + elog(NOTICE, "%d trigger(s) on %s %s.",
> + changed,
> + NameStr(rel-
Here is new patch with pg_dump modification.
Bruce Momjian wrote:
> I am waiting for pg_dump support for this patch.
>
> ---
>
> Satoshi Nagayasu wrote:
>
>>Bruce Momjian wrote:
>>
>>>I am not sure what to do with this patc
I am waiting for pg_dump support for this patch.
---
Satoshi Nagayasu wrote:
> Bruce Momjian wrote:
> > I am not sure what to do with this patch. It is missing dump
> > capability, there is no clause to disable all triggers
Satoshi Nagayasu wrote:
> Bruce Momjian wrote:
> > I am not sure what to do with this patch. It is missing dump
> > capability, there is no clause to disable all triggers on a table, and
> > it uses a table owner check when a super user check is required (because
> > of referential integrity).
> >
Bruce Momjian wrote:
> I am not sure what to do with this patch. It is missing dump
> capability, there is no clause to disable all triggers on a table, and
> it uses a table owner check when a super user check is required (because
> of referential integrity).
>
> Satoshi, are you still working o
Bruce Momjian wrote:
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
From a user's view, a trigger implement
I am not sure what to do with this patch. It is missing dump
capability, there is no clause to disable all triggers on a table, and
it uses a table owner check when a super user check is required (because
of referential integrity).
Satoshi, are you still working on it? If not does someone else
Gavin Sherry wrote:
> On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
>
> > Hi all,
> >
> > Here is a first patch to allow these commands.
> >
> > > ALTER TABLE ENABLE TRIGGER
> > > ALTER TABLE DISABLE TRIGGER
> >
>
> Hmmm.. just thinking about it for a second. I wonder if we should also
> suppor
Satoshi Nagayasu wrote:
>Hi all,
>
>Here is a first patch to allow these commands.
>
>
>
>>ALTER TABLE ENABLE TRIGGER
>>ALTER TABLE DISABLE TRIGGER
>>
>>
>
>Bruce said to allow them only super-user,
>but currently this patch allows also the table owner.
>
>
>
It would be convenient if
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> The table owner can drop and create triggers - so why shouldn't they be
> able to enable and disable them?
Not triggers belonging to RI constraints on other tables.
regards, tom lane
---(end of
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
> Hi,
>
> Gavin Sherry wrote:
> > Hmmm.. just thinking about it for a second. I wonder if we should also
> > support:
> >
> > ALTER TABLE DISABLE TRIGGERS
>
> I found some RDBMSes are supporting 'DISABLE TRIGGER ALL TRIGGERS' command.
>
> Does anyone kno
Hi,
Gavin Sherry wrote:
> Hmmm.. just thinking about it for a second. I wonder if we should also
> support:
>
> ALTER TABLE DISABLE TRIGGERS
I found some RDBMSes are supporting 'DISABLE TRIGGER ALL TRIGGERS' command.
Does anyone know about the SQL99 spec?
--
NAGAYASU Satoshi <[EMAIL PROTECTED]
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
> Hi all,
>
> Here is a first patch to allow these commands.
>
> > ALTER TABLE ENABLE TRIGGER
> > ALTER TABLE DISABLE TRIGGER
>
Hmmm.. just thinking about it for a second. I wonder if we should also
support:
ALTER TABLE DISABLE TRIGGERS
which woul
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
> Hi all,
>
> Here is a first patch to allow these commands.
>
> > ALTER TABLE ENABLE TRIGGER
> > ALTER TABLE DISABLE TRIGGER
There are three other areas which are worth looking at:
a) We may defer the execution of some triggers to the end of the
t
There is one more fix...
> + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
> + SnapshotNow, 1,
> keys);
'1' was incorrect, must be '2'.
> + tgscan = systable_beginscan(tgrel, TriggerRelidNameIndexId, true,
>
Thanks for comments, Neil.
Some are fixed.
Neil Conway wrote:
> Also, you should probably skip the simple_heap_update() if the user
> tries to disable an already-disabled trigger, to avoid pointless MVCC
> bloat (and same for enabling an already-enabled trigger, of course).
Do we need some log
Hi,
BTW, the Postgres convention is to submit patches in context diff format
(diff -c).
Satoshi Nagayasu wrote:
+ while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
+ {
+ HeapTuple newtup = heap_copytuple(tuple);
+ Form_pg_trigger pg_trigger = (
> I said why _shouldn't_. I was agreeing with you.
Oops. Sorry.
I don't know why only super-user shold be able to enable/disable tirggers.
I believe the table owner want to enable/disable triggers,
because I always need it.
Loading huge data set into the table with triggers(or fk) is very pai
Satoshi Nagayasu wrote:
>>The table owner can drop and create triggers - so why shouldn't they be
>>able to enable and disable them?
>
>
> For convenience or easy operation.
>
> I believe the user doesn't like to create same triggers again and again.
I said why _shouldn't_. I was agreeing wi
> The table owner can drop and create triggers - so why shouldn't they be
> able to enable and disable them?
For convenience or easy operation.
I believe the user doesn't like to create same triggers again and again.
Christopher Kings-Lynne wrote:
>>>ALTER TABLE ENABLE TRIGGER
>>>ALTER TABLE
>>ALTER TABLE ENABLE TRIGGER
>>ALTER TABLE DISABLE TRIGGER
>
>
> Bruce said to allow them only super-user,
> but currently this patch allows also the table owner.
The table owner can drop and create triggers - so why shouldn't they be
able to enable and disable them?
Chris
---
30 matches
Mail list logo
