Re: array of domain types

On 02.06.2016 17:22, Tom Lane wrote:
> konstantin knizhnik <k.knizhnik@postgrespro.ru> writes:
>> Attached please find patch for DefineDomain function.
> You didn't attach the patch,

Sorry, but I did attached the patch - I see the attachment in my mail 
received from the group.
Multidimensional arrays work fine:

knizhnik=# SELECT '{{14},{20}}'::teenager[][];
ERROR:  value for domain teenager violates check constraint "teenager_check"
LINE 1: SELECT '{{14},{20}}'::teenager[][];               ^
knizhnik=# SELECT '{{14},{19}}'::teenager[][];  teenager
------------- {{14},{19}}
(1 row)

knizhnik=# SELECT ('{{14},{19}}'::teenager[][])[1][1]; teenager
----------       14
(1 row)


Domain of array of domain also works:


knizhnik=# create domain teenager_groups as teenager[];
CREATE DOMAIN
knizhnik=# SELECT '{{14},{19}}'::teenager_groups; teenager_groups
----------------- {{14},{19}}
(1 row)

knizhnik=# SELECT '{{14},{20}}'::teenager_groups;
ERROR:  value for domain teenager violates check constraint "teenager_check"
LINE 1: SELECT '{{14},{20}}'::teenager_groups;


>   but in any case, I would be astonished
> if there is no work required beyond creating the matching array type.
> The reverse case (domains over arrays) has half a dozen special cases
> required to make it work smoothly.  Probably the considerations on this
> side are totally different, but it's hard to believe there aren't any.
>
> One case that seems likely to be pretty squishy is an array of a domain
> over an array type.  One would wish to be able to do foo[2][4] to
> extract an element of the contained array.  That won't work as-is
> because the notation will be taken as a multi-dimensional subscript,
> but I would expect that (foo[2])[4] should work.  Does it?  Does
> ruleutils.c always include the necessary parens when reverse-listing
> such a construct?  Is it possible to assign to such a sub-element,
> and if so, do the domain constraints get checked properly?
>
> Domain over an array that is of a domain type might be another fun
> case.
>
>             regards, tom lane

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company