On Wed, 2008-11-05 at 14:38 -0500, Merlin Moncure wrote:
[....]
> >
> >> It's more complicated than it looks (triggers).
> >
> > Could you give me pointers where I could get some more information on
[....]
> matter, the system has several not-easily-removed assumptions that a
> SELECT command won't fire any triggers at all --- which would break down
> if we allowed constructs like
>
> SELECT ... FROM (INSERT ... RETURNING ...) ...
>
I can only say I wish I could be of any help here .... but database
coding is way out of my league.
The "SELECT ... FROM (INSERT ..." seam so close to "INSERT ...
RETURNING...", its hard to believe it's so far away.
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. Otherwise (for legacy
applications) it may be disabled like it happened in the past, for other
"not so standard" (or should I rather say, new and untested by wider
audience) postgress features.
But I understand, 8.4 gets us a little closer to the goal with SQL
functions able to return what SELECT cannot.
Thenx for the pointer, the reading was enlightening.
-R
