> Phil Endecott <[EMAIL PROTECTED]> writes:
>> I would understand this if I were doing an "ALTER TABLE", for example.
>> But does adding or removing a trigger really count as "schema-altering"?
>
> [ shrug... ] Hard to say. Probably depends a lot on what the trigger
> does. I suppose we could
Phil Endecott <[EMAIL PROTECTED]> writes:
> I would understand this if I were doing an "ALTER TABLE", for example.
> But does adding or removing a trigger really count as "schema-altering"?
[ shrug... ] Hard to say. Probably depends a lot on what the trigger
does. I suppose we could at least
Tom Lane wrote:
Phil Endecott <[EMAIL PROTECTED]> writes:
It seems less scary when you think of metadata as just being the content
of more tables, rather than something special.
PG does just fine with handling metadata changes transactionally.
However, most operations that affect a table's schema
Phil Endecott <[EMAIL PROTECTED]> writes:
> It seems less scary when you think of metadata as just being the content
> of more tables, rather than something special.
PG does just fine with handling metadata changes transactionally.
However, most operations that affect a table's schema at all will
Greg asked:
> > is "DROP TRIGGER" transaction safe?... I mean, could I do:
> >
> > BEGIN
> > DROP TRIGGER category_mv_ut;
> > ... insert rows
> > ... update materialized view table
> > CREATE TRIGGER category_mv_ut AFTER UPDATE ON items
> > FOR EACH ROW EXECUTE PROCEDURE update_ut();
> > COMMIT;
>Greg wrote:
> > is "DROP TRIGGER" transaction safe?... I mean, could I do:
> >
> > BEGIN
> > DROP TRIGGER category_mv_ut;
> > ... insert rows
> > ... update materialized view table
> > CREATE TRIGGER category_mv_ut AFTER UPDATE ON items
> > FOR EACH ROW EXECUTE PROCEDURE update_ut();
> > COMMIT;
Greg wrote:
> is "DROP TRIGGER" transaction safe?... I mean, could I do:
>
> BEGIN
> DROP TRIGGER category_mv_ut;
> ... insert rows
> ... update materialized view table
> CREATE TRIGGER category_mv_ut AFTER UPDATE ON items
> FOR EACH ROW EXECUTE PROCEDURE update_ut();
> COMMIT;
>
> .. without oth
Hello,
I have asked about this before, but I just haven't been able to get
anywhere with it yet.. I'm hoping someone can help me?
Here is my original function and trigger:
CREATE OR REPLACE VIEW items_category AS select count(*) AS count
,b.category,nlevel(b.category) AS level,
subpath(b.cate
1) I have some TRIGGER BEFORE INSERT created explicitly, and other(s)
created implicitly, through default constraints. What is their execution
order?
2) Are the changes made by the first visible to the following ones?
---(end of broadcast)---
TIP 5