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

On Mon, May 09, 2011 at 11:32:28PM -0400, Tom Lane wrote:
> 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
>       break applications that were relying on the function result
>       being considered of the domain type
>     * re-apply domain checks on the function result, which would be
>       a performance hit and possibly again result in unobvious
>       breakage
>     * 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.

Though I've never used a domain over an array type, I'd strongly prefer #2.  As
best I can tell, the only functions that could need to do this are those that
have an anyarray argument and also an anyarray return type.  In core, that's
array_append, array_prepend, array_cat, array_larger, array_smaller, max, and
min.  The last four always return an input unchanged, so only the first three
would actually check anything.  I'm not seeing, offhand, any need to add new
validation to PLs.

The parse-time breakage of #3 is a nice tool during your upgrade QA, but the
long-term semantics are considerably worse for wear.

I see nothing to recommend #1.

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

What else but the type seen by subscripting a datum of the ANYARRAY type?

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

The domain and its base type share an element type, but how does that
necessitate any further removal of domain-ness?

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

Agreed.

nm