Re: Support UPDATE table SET(*)=...

>>>>> "Tom" == Tom Lane <tgl@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
directlywould>> be. Consider the case where foo and reference_foo match with the>> exception of dropped columns; the
codeas 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 wouldTom> have a command that explicitly tells the system
toinsert orTom> update only the enumerated columns.  That will *not* work asTom> 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
inconsistencieswith 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 seeTom> your point though that (*) is more
notationallyconsistent withTom> that case.  Maybe we should be looking at trying to implement T641Tom> 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-timeTom> 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)