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

"J. Greg Davidson" <greg@ngender.net> writes:
>       * Tighten casting checks for domains based on arrays (Tom Lane)        
>         When a domain is based on an array type,..., such a domain type
>         is no longer allowed to match an anyarray parameter of a
>         polymorphic function, except by explicitly downcasting it to the
>         base array type.        
> This will require me to add hundreds of casts to my code.  I do not get
> how this will "Tighten casting checks".  It will certainly not tighten
> my code!  Could you explain how it is good to not be able to do array
> operations with a type which is an array?

The discussion that led up to that decision is in this thread:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg01362.php
specifically here:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg01545.php

The previous behavior was clearly broken.  The new behavior is at least
consistent.  It might be more user-friendly if we did automatic
downcasts in these cases, but we were not (and still are not) doing
automatic downcasts for domains over scalar types in comparable cases,
so it's not very clear why domains over array types should be treated
differently.

To be concrete, consider the function array_append(anyarray, anyelement)
yielding anyarray.  Suppose we have a domain D over int[] and the call
array_append(var_of_type_D, 42).  If we automatically downcast the
variable to int[], should the result of the function be considered to be
of type D, or type int[]?  This isn't a trivial distinction because
choosing to consider it of type D means we have to re-check D's domain
constraints, which might or might not be satisfied by the modified
array.  Previous releases considered the result to be of type D,
*without* rechecking the domain constraints, which was flat out wrong.

So we basically had three alternatives to make it better:* downcast to the array type, which would possibly silently
breakapplications that were relying on the function result  being considered of the domain type* re-apply domain checks
onthe function result, which would be  a performance hit and possibly again result in unobvious  breakage* explicitly
breakit 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.

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?  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.
        regards, tom lane