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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)