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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
