Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 10, 2011 at 1:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Mon, May 9, 2011 at 11:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> 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
>>> Aren't any applications that would be broken by #1 broken already?
>> My point is that doing #1 would break them *silently* --- if you did
>> have a problem, figuring out what it was could require a great deal
>> of sleuthing.
> Eh, I'm confused. Explain further?
The previous behavior was effectively to allow a domain-over-array type
to match the ANYARRAY symbol, without doing anything else special with
it. In particular if the function returned ANYARRAY then its output
would be taken to be of the domain type, which is wrong since the
function might produce an array value that doesn't meet the domain's
constraints.
We could, and perhaps should, instead downcast the domain to the array
type, which would imply that ANYARRAY is matching the base type not the
domain, and in particular that a declared ANYARRAY result type means the
base type not the domain. The things that were bothering me about this
at the time were (1) it would be a silent change of behavior, and (2)
it doesn't seem very consistent to handle domain-to-ANYARRAY matching
this way without also doing something with domain-to-ANYELEMENT
matching.
An example of the inconsistency is that something like
create domain myi as int; select array[1,2,3] || 4::myi;
fails with "operator does not exist: integer[] || myi", not only in HEAD
but all recent releases. If we're going to downcast a domain-over-array
to plain array to allow it to be used with array_append, it's not clear
why we don't allow myi to be automatically downcast to int for the same
purpose.
However, exactly what we ought to do instead isn't entirely clear, and
when I brought it up back in October no one seemed to care enough to
pursue the matter. So I just left both cases as throwing error, which
seemed the most conservative course.
I'm still willing to talk about alternatives, though it seems a bit
late in the 9.1 cycle to be designing behaviors.
regards, tom lane