Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays - Mailing list pgsql-hackers

Given:
 CREATE DOMAIN int_array AS int[];

The operator [] works fine in 4.1beta1:
 SELECT (ARRAY[1,2,3]::int_array)[1];

proving that int_array is an array type with element type int.

It is inconsistent that other array functions and operators don't work.

On Mon, 2011-05-09 at 23:32 -0400, Tom Lane wrote:

> So we basically had three alternatives to make it better:
>     #1 downcast to the array type, which would possibly silently
>       break applications that were relying on the function result
>       being considered of the domain type

I do not think of this as "Downcasting int_array to int[]" but as
allowing an ANYARRAY to match int_array which is an array type.
Since no cast is logically required, the return type is the same
as the first argument type, as expected and as PostgreSQL has done
for some time.

>     #2 re-apply domain checks on the function result, which would be
>       a performance hit and possibly again result in unobvious
>       breakage

If the function result is a new value then nothing is being re-applied.
If it is an existing value of the domain type which was passed in or
extracted from a data structure, then the domain checks have already
been applied.  This is a red herring.

>     #3 explicitly break it by throwing a parse error until you
>       downcast (and then upcast the function result if you want)

> I realize that #3 is a bit unpleasant, but are either of the other two
> better?  At least #3 shows you where you need to check for problems.

Wrapping most (but not all) of your array operations in downcasts and
upcasts is horrible.

> There is another issue that wasn't really mentioned in the previous
> thread, which is that if we are matching a domain-over-array to a
> function's ANYARRAY argument, what exactly should be allowed to match to
> ANYELEMENT --- or if the function returns ANYELEMENT, what should the
> imputed result type be?

Since PostgreSQL allows indexing of the domain type, we already know
the answer.  I don't even get why there is confusion abou the
element type of an array.

> AFAICS it's impossible to give an answer to
> that without effectively deciding that function argument matching
> smashes the domain to its base type (the array type).  It's not very
> clear what's the point of a domain type if every operation on it is
> going to neglect its domain-ness.

Yes, what is the point of neglecting the domain-ness of a domain type
by being forced to downcast it to an unchecked type before (some) array
operations?  If a value is being constructed of a domain-type which has
constraints, check them.  When I don't want the security of a domain
type I can cast it to its representation type before I passed it, but
it seems bizarre to be required to do such a thing!

I did read the previous threads some time ago. They seemed mostly to be
concerned with discussing the internal implementation of these matters
and the typmod feature (which I still don't understand).  The internal
algorithms and deta structures which PostgreSQL uses to internally
represent SQL types and operations are a weak justification for
PostgreSQL's behavior - they can be changed if they are wrong.

I am still hoping to get rid of my domains which are arrays when
PostgreSQL supports arrays of elements which are of domain types.
Could we at least defer this change until that is done?

_Greg