Robert Haas writes:
> On Tue, Jan 16, 2024 at 11:46 AM Tom Lane wrote:
>> Also, we already
>> treat the multirange as dependent for some things:
> But this seems like an entirely valid point.
Yeah, it's a bit of a muddle. But there is no syntax for making
a standalone multirange type, so it
On Tue, Jan 16, 2024 at 11:46 AM Tom Lane wrote:
> They're by no means independent. What would it mean to have a
> multirange without the underlying range type?
It would mean just that - no more, and no less. If it's possible to
imagine a data type that stores pairs of values from the
Robert Haas writes:
> On Mon, Jan 15, 2024 at 2:28 PM Tom Lane wrote:
>> 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
On Mon, Jan 15, 2024 at 2:28 PM Tom Lane wrote:
> 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
Robert Haas writes:
> On Mon, Jan 15, 2024 at 1:27 PM Tom Lane 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
On Mon, Jan 15, 2024 at 1:27 PM Tom Lane 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
d=# create type varbitrange as range (subtype = varbit);
CREATE TYPE
d=# \dT+
List of data types
Schema | Name | Internal name | Size | Elements | Owner |
Access privileges | Description
