From: | Naveed Alam <naveedalam(dot)gis(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal / proof of concept: Triggers on VIEWs |
Date: | 2010-08-06 07:56:01 |
Message-ID: | AANLkTimdhSqqP+jsHLu+eZu+SHZ9aTWzmm4nWL7g0o1D@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
aoa how can i connect my postgres database to manifold?
Regards?
On Fri, Aug 6, 2010 at 12:49 PM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>wrote:
> On 4 August 2010 15:08, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
> wrote:
> > On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
> >>
> >> On 4 August 2010 14:43, Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
> >> wrote:
> >>>
> >>> I'm not sure I understand. RETURNING in DELETE on a table fetches the
> >>> old
> >>> value after it was DELETEd, so it really is what the tuple was before
> the
> >>> DLETE, not what is seen by the snapshot. In a BEFORE DELETE trigger,
> the
> >>> row is always locked so it can't change after the trigger is fired.
> >>>
> >>
> >> Ah, I think I mis-understood. If I understand what you're saying
> >> correctly, you're worried that the row might have been modified in the
> >> same query, prior to being deleted, and you want RETURNING to return
> >> the updated value, as it was when it was deleted.
> >
> > I'm mainly concerned about concurrently running transactions.
> >
>
> Sorry for the delay replying.
>
> Once again, I think I mis-understood your point. I think that the
> database can't really lock anything before firing the trigger because
> the view might contain grouping/aggregates or even not be based on any
> real tables at all, so it would be impossible to work out what to
> lock. Thus it would be up to the trigger function to get this right.
> In the simplest case, for a DELETE, this might look something like:
>
> CREATE OR REPLACE FUNCTION instead_of_delete_trig_fn()
> RETURNS trigger AS
> $$
> BEGIN
> DELETE FROM base_table WHERE pk = OLD.pk;
> IF NOT FOUND THEN RETURN NULL; END IF;
>
> RETURN OLD;
> END;
> $$
> LANGUAGE plpgsql;
>
> If 2 users try to delete the same row, the second would block until
> the first user's transaction finished, and if the first user
> committed, the second user's trigger would return NULL, which the
> database would signal as no rows deleted.
>
> Regards,
> Dean
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Fowler | 2010-08-06 08:04:15 | Re: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function |
Previous Message | Simon Riggs | 2010-08-06 07:53:22 | Re: MERGE Specification |