Andrew Gierth <and...@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes: > Tom> and not at all robust against schema changes (the same problem as > Tom> with the patch's approach to UPDATE).
> 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. AFAICS you've got that backwards. As I illustrated upthread, after parse-time expansion we would have a command that explicitly tells the system to insert or update only the enumerated columns. That will *not* work as desired if columns are added later, and (if it's in a rule) I would expect the system to have to fail a DROP command trying to drop one of those named columns, the same way you can't drop a column referenced in a view/rule today. On the other hand, if it's a composite-type assignment, then dealing with things like dropped columns becomes the system's responsibility, and we already have code for that sort of thing. > ... 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. Right, but we should be trying to move in that direction. I see your point though that (*) is more notationally consistent with that case. Maybe we should be looking at trying to implement T641 in full and then including (*) as a special case of that. Anyway, my core point here is that we should avoid parse-time expansion of the column set. The *only* reason for doing that is that it makes the patch simpler, not that there is some functional advantage; in fact there are considerable functional disadvantages as we've just been through. So I do not want to commit a patch that institutionalizes those disadvantages just for short-term implementation simplicity. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers