Robert Haas <robertmh...@gmail.com> writes: > On Tue, May 10, 2011 at 1:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> On Mon, May 9, 2011 at 11:32 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers