aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-02-14 11:30:39 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2024-02-14 11:30:39 -0500
commit3e8235ba4f9cc3375b061fb5d3f3575434539b5f (patch)
tree44b71342fadc8cb3dc5e0fe50359ee2e23c31506 /doc/src
parentbd8fc1677b88ed80e4e00e0e46401ec537952482 (diff)
downloadpostgresql-3e8235ba4f9cc3375b061fb5d3f3575434539b5f.tar.gz
postgresql-3e8235ba4f9cc3375b061fb5d3f3575434539b5f.zip
Fix multiranges to behave more like dependent types.
For most purposes, multiranges act like dependent objects of the associated range type: you can't create them separately or drop them separately. This is like the way that autogenerated array types behave. However, a couple of points were overlooked: array types automatically track the ownership of their base type, and array types do not have their own permissions but use those of the base type, while multiranges didn't emulate those behaviors. This is fairly broken, mainly because pg_dump doesn't think it needs to worry about multiranges as separate objects, and thus it fails to dump/restore ownership or permissions of multiranges. There's no apparent value in letting a multirange diverge from its parent's ownership or permissions, so let's make them act like arrays in these respects. However, we continue to let multiranges be renamed or moved to a different schema independently of their parent, since that doesn't break anything. Discussion: https://postgr.es/m/1580383.1705343264@sss.pgh.pa.us
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions