Re: [HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Aggregates sound interesting, though I'm not sure how useful they'd > actually be. I think something like > FOR v_row IN (UPDATE ... RETURNING ...) > would be a lot more useful (if it's not already in the patch). It's not. I thought about it for a bit but there are some nasty gotchas if the planner decides it needs to rescan the subquery multiple times. I'd say that's something to leave for 8.3 ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING
On Sun, Aug 13, 2006 at 03:54:18PM -0400, Tom Lane wrote: > which is that you can use aggregate functions in the RETURNING list and > get a single-row result that is aggregated across all affected rows. > It's too late to consider implementing that for 8.2, I fear, but I think > maybe we should put it on the TODO list for later. Aggregates sound interesting, though I'm not sure how useful they'd actually be. I think something like FOR v_row IN (UPDATE ... RETURNING ...) would be a lot more useful (if it's not already in the patch). -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING
Tom Lane wrote: > With STRICT: you get an error unless exactly one row is affected. > > This prevents the incomplete-execution problem. > > BTW, some googling indicates that Oracle's equivalent PL/SQL construct > supports only the exactly-one-row case. But they have an alternative, > which is that you can use aggregate functions in the RETURNING list and > get a single-row result that is aggregated across all affected rows. > It's too late to consider implementing that for 8.2, I fear, but I think > maybe we should put it on the TODO list for later. Interesting, an aggregate to combine the rows. Remembering how much trouble/discussion the STRICT was, I am unsure if we should add this to the TODO unless we get someone who likes it. ;-) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster