Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 15, 2024 at 1:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That's pretty broken, isn't it? joe would own the multirange if he'd
>> created the range to start with. Even if you think the ownerships
>> ideally should be separable, this behavior causes existing pg_dump
>> files to restore incorrectly, because pg_dump assumes it need not emit
>> any commands about the multirange.
> I agree that pg_dump doing the wrong thing is bad, but the SQL example
> doesn't look broken if you ignore pg_dump.
I'm reasoning by analogy to array types, which are automatically
created and automatically updated to keep the same ownership
etc. properties as their base type. To the extent that multirange
types don't act exactly like that, I say it's a bug/oversight in the
multirange patch. So I think this is a backend bug, not a pg_dump
bug.
> I have a feeling that the
> source of the awkwardness here is that one SQL command is creating two
> objects, and unlike the case of a table and a TOAST table, one is not
> an implementation detail of the other or clearly subordinate to the
> other.
How is a multirange not subordinate to the underlying range type?
It can't exist without it, and we automatically create it without
any further information when you make the range type. That smells
a lot like the way we handle array types. The array behavior is of
very long standing and surprises nobody.
> But how does that prevent us from making pg_dump restore the
> ownership and permissions on each separately? If ownership is a
> problem, aren't permissions also?
Probably, and I wouldn't be surprised if we've also failed to make
multiranges follow arrays in the permissions department. An
array type can't have an ACL of its own, IIRC.
regards, tom lane