>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> Now this I think is wrong; I think it's just as robust against >> schema changes as using the composite value directly would >> be. Consider the case where foo and reference_foo match with the >> exception of dropped columns; the code as it is should just work, >> while a variant that used the composite values would have to >> explicitly deal with that. Tom> AFAICS you've got that backwards. Tom> As I illustrated upthread, after parse-time expansion we would Tom> have a command that explicitly tells the system to insert or Tom> update only the enumerated columns. That will *not* work as Tom> desired if columns are added later, Where "later" is between parse analysis and execution - and if this query is not in a rule, then any such schema change will force a re-analysis if it's a prepared statement, no? and otherwise, we have the tables locked against schema changes anyway? Is there a failure case here that doesn't involve rules? Tom> and (if it's in a rule) well, the example I gave is not something that anyone in their right minds would try and put in a rule. >> ... The alternative of >> set * = populate_record(foo, new_values) >> is less satisfactory since it introduces inconsistencies with the case >> where you _do_ want to specify explicit columns, unless you also allow >> set (a,b) = row_value >> which is required by the spec for T641 but which we don't currently >> have. Tom> Right, but we should be trying to move in that direction. I see Tom> your point though that (*) is more notationally consistent with Tom> that case. Maybe we should be looking at trying to implement T641 Tom> in full and then including (*) as a special case of that. I would have liked to have done that, but that would have raised the complexity of the project from "Atri can take a stab at this one with negligible supervision" to "Andrew will have to spend more time than he has conveniently available staring at the raw parser to try and make it work". As I said, the perfect is the enemy of the good. Tom> Anyway, my core point here is that we should avoid parse-time Tom> expansion of the column set. Parse-time expansion of * is pretty widespread elsewhere. Changing that for this one specific case seems a bit marginal to me - and if the main motivation to do so is to support cases in DML rules, which are already a foot-bazooka, I think it's honestly not worth it. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
