Re: [HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING

2006-08-14 Thread Jim C. Nasby
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

Re: [HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING

2006-08-14 Thread Tom Lane
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

[HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING

2006-08-13 Thread Tom Lane
Jonah's patch for INSERT/etc RETURNING included changes to allow the RETURNING data to be assigned to plpgsql variables, similar to plpgsql's version of SELECT INTO. For instance, collect a serial column's assigned value with declare x int; begin insert into mytab

Re: [HACKERS] plpgsql and INSERT/UPDATE/DELETE RETURNING

2006-08-13 Thread Bruce Momjian
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