Re: array of domain types

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Rod Taylor <rod(dot)taylor(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: array of domain types
Date: 2016-06-03 17:45:08
Message-ID: ec60ca0f-a88f-a318-599d-592d64317d12@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/3/16 11:50 AM, Konstantin Knizhnik wrote:
> Originally I was mostly interested in domains as kind of typedefs:
> convenient way to assign type to some particular kind of columns,
> for example object reference used in ORM.
> There are two main goals of using domain here:
> 1. Be able to easily change representation of object identifier, for
> example from integer to bigint.
> 2. Detect all columns containing references (distinguish them from
> columns containing just normal integers).
> I do not see any other mechanism in PostgreSQL which can address this
> problem (for example user defined type can not help here).
>
> I wonder if it is possible to support arrays of domain which do not have
> constraints?
> Or such partial support is worser than prohibiting arrays of domains at all?

I don't know that domains without constraints gets you terribly much. At
that point you could just create a brand new type using all the existing
infrastructure (though admittedly that's a LOT more work than CREATE
DOMAIN).

I definitely think that domains should work the way you're envisioning.
To me, they should be the exact same thing as any other type, except
that they have constraints attached and a different named. You should be
able to use them everywhere and in every way that you currently use a
type. Ideally you'd even be able to create casts against them.

I'm not suggesting you try and fix all those things at once, but I don't
think we should add only partial support for arrays of domains. If you
can have a domain array, it should work exactly how you'd expect,
including all of the constraint checking.

Before focusing further on the code, I think you should focus on adding
appropriate regression tests to make sure things work correctly. I'm not
sure what's currently tested, but what comes to mind is making certain
that constraints work with a domain array when used both by themselves
and as part of a composite type:

- as an argument to a function
- inside a sql function
- as a plpgsql variable
- inside a plpgsql function
- as a table column

So that's 5 x 2 (once for domain[], once for create type blah(x
domain[])) test cases. There might be some other cases that are missing
(what cast testing needs to happen?)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-06-03 17:47:38 Re: Perf Benchmarking and regression.
Previous Message Andres Freund 2016-06-03 17:43:14 Re: Perf Benchmarking and regression.