public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Robert Haas <[email protected]>
Cc: [email protected]
Subject: Re: ALTER TYPE OWNER fails to recurse to multirange
Date: Mon, 15 Jan 2024 14:28:31 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoZZFj_XQi9_nJ7f-6jQk=-m+Ki9RTAehBWf9E21bVmS+Q@mail.gmail.com>
References: <[email protected]>
	<CA+TgmoZZFj_XQi9_nJ7f-6jQk=-m+Ki9RTAehBWf9E21bVmS+Q@mail.gmail.com>

Robert Haas <[email protected]> writes:
> On Mon, Jan 15, 2024 at 1:27 PM Tom Lane <[email protected]> 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

view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: ALTER TYPE OWNER fails to recurse to multirange
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox