On 2018-11-09 18:07, Alvaro Herrera wrote: > On 2018-Nov-09, Jürgen Strobel wrote: > >> Regarding your example, what I expected is that *both* inserts would >> consistently result in a tuple of (1, 42) since p should route the >> insert to p1 and use p1's defaults. The current inconsistent behavior is >> the heart of the bug. > > I think that would be sensible behavior, as long as the partition > doesn't override values for the partitioning column -- i.e. if the > default values don't re-route the tuple to another partition, I think we > should use the partition's default rather than the parent. This says we > should expand defaults after routing. However, can we really route if > we haven't expanded defaults? In general, we may be lacking values for > some columns of the partition key. Another point: if we've already > expanded defaults when processing at the parent level, when we reach the > partition we don't know which values are still missing default > expansion, or which defaults coming from the parent ought to be > re-expanded. > > So this looks to be a bit of a landmine. > > In any case it seems really hard to see this is as a bug that we would > fix in back-branches. >
I am slightly confused now, I thought this landmine was already fixed in master and what remains is only whether to backport it or not? Which I guess depends on whether this is classified as a bug or not. Since the fix has the potential to break current applications and the documentation is vague about wanted behavior I think it would be sensible to add a warning only, even if we agree to call it a bug. Best regards, Jürgen