Re: Proposal: CREATE/ALTER DOMAIN ... STORAGE/COMPRESSION = ...

From: Nikita Malakhov <hukutoc(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: CREATE/ALTER DOMAIN ... STORAGE/COMPRESSION = ...
Date: 2022-08-21 18:04:50
Message-ID: CAN-LCVNNRRUZJAaCv3oss4FBAi2XszmkeZTGMF96y16DhSz6fQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!
I agree, domains are supposed to define data types only and are not meant
to impact
how these types are stored. Storage and compression strategy differ for one
given type
from table to table and must be defined explicitly, except for default.
Also, such implicit-like
storage and compression definition would very likely be the source of
errors or unpredictable
behavior while using such data types.

On Sat, Aug 20, 2022 at 10:47 AM Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:

> On 17.08.22 11:43, Aleksander Alekseev wrote:
> > Do you think it will be useful to specify STORAGE and/or COMPRESSION
> > for domains?
>
> Domains are supposed to a logical construct that restricts the accepted
> values for a data type (it's in the name "domain"). Expanding that into
> a general "column definition macro" seems outside its scope. For
> example, what would be the semantics of this when such a domain is a
> function argument or return value?
>
> > As an example, this will allow creating an alias for TEXT with
> > EXTERNAL storage strategy. In other words, to do the same we do with
> > ALTER TABLE, but for types. This feature is arguably not something
> > most people are going to use, but it shouldn't be difficult to
> > implement and/or maintain either.
>
> Considering how difficult it has been to maintain domains in just their
> current form, I don't believe that.
>
>
>
>
>

--
Regards,
Nikita Malakhov
Postgres Professional
https://postgrespro.ru/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2022-08-21 18:45:14 num_sa_scans in genericcostestimate
Previous Message Anton A. Melnikov 2022-08-21 15:32:36 Re: [BUG] Logical replica crash if there was an error in a function.