Thread: Proposal: CREATE/ALTER DOMAIN ... STORAGE/COMPRESSION = ...
Hi hackers, Do you think it will be useful to specify STORAGE and/or COMPRESSION for domains? 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. Thoughts? -- Best regards, Aleksander Alekseev
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.
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.eisentraut@enterprisedb.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.