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 by Tom, with
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.
---
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.
---
Satoshi
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 -cr
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
---
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 messages (Maybe even four:
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 really a gain in
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
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 patch. It is
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,
+
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),
+ enable ?
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 on
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
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 on it?
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).
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
Hi all,
Here is a first patch to allow these commands.
ALTER TABLE table ENABLE TRIGGER trigname
ALTER TABLE table DISABLE TRIGGER trigname
Bruce said to allow them only super-user,
but currently this patch allows also the table owner.
If we need to restrict these operations,
we have to add
ALTER TABLE table ENABLE TRIGGER trigname
ALTER TABLE table DISABLE TRIGGER trigname
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?
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 table ENABLE TRIGGER trigname
ALTER
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 with you.
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
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 =
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
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,
+
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
Hi all,
Here is a first patch to allow these commands.
ALTER TABLE table ENABLE TRIGGER trigname
ALTER TABLE table DISABLE TRIGGER trigname
There are three other areas which are worth looking at:
a) We may defer the execution of some triggers
On Fri, 1 Jul 2005, Satoshi Nagayasu wrote:
Hi all,
Here is a first patch to allow these commands.
ALTER TABLE table ENABLE TRIGGER trigname
ALTER TABLE table DISABLE TRIGGER trigname
Hmmm.. just thinking about it for a second. I wonder if we should also
support:
ALTER TABLE DISABLE
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,
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
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
Satoshi Nagayasu wrote:
Hi all,
Here is a first patch to allow these commands.
ALTER TABLE table ENABLE TRIGGER trigname
ALTER TABLE table DISABLE TRIGGER trigname
Bruce said to allow them only super-user,
but currently this patch allows also the table owner.
It would be
30 matches
Mail list logo
