From: | "Dennis Brakhane" <brakhane(at)googlemail(dot)com> |
---|---|
To: | "Rafal Pietrak" <rafal(at)zorro(dot)isa-geek(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: INSERT .... RETURNING |
Date: | 2008-11-07 19:45:01 |
Message-ID: | 226a19190811071145w23807798vc6e0c8572a277731@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Nov 6, 2008 at 8:49 AM, Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> wrote:
> One comment I'd like to make as total lamer on the subject, is that the
> assumption on SELECT (that it's not firing triggers), could potentially
> be resolved by a *global* or "database" configuration option - once
> selected, the SQL programmers' responsibility would be: not to assume
> that on SELECT at the application layer.
I think Tom meant that PostgreSQL's code assumes that select fires no triggers.
Hence, triggers (and probably constraints) wouldn't fire if you did a
select (insert ... returning).
So your setting would basically mean "make triggers fire some of the
time, and I don't
care about data consistency either". I doubt any sane person would
activate it ;)
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2008-11-07 20:11:33 | Re: Specifying text to substitute for NULLs in selects |
Previous Message | Erik Jones | 2008-11-07 19:26:32 | Re: After delete trigger problem |