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
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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to