Re: Domains versus arrays versus typmods

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Domains versus arrays versus typmods
Date: 2010-10-21 17:36:16
Message-ID: 26853.1287682576@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So we will downcast myia to int[], or at least one might assume
>> that's what's happening. But actually it's worse than that: the
>> result of this operation is thought to be myia not int[], because
>> myia itself is taken as matching ANYARRAY, and the operator result
>> is the same ANYARRAY type.

> That is actually what I would want and expect. Let's say I have an
> array of attorney bar numbers, and I add one more as a literal.
> While an argument could be made that the integer should be cast to
> a bar number before being added to the array, we don't require that
> for an assignment to a simple variable in the domain, so it would be
> surprising to require a cast here, and even more surprising for the
> concatenation to result in an array of primitive integers rather
> than a array of attorney bar numbers.

I disagree with that argument: you are confusing an array over a domain
type with a domain over an array type. In the latter case, the domain
could have additional constraints (such as the length constraint in my
other example), and there's no reason to assume that || or other array
operators would preserve those constraints.

A perhaps comparable example is

create domain verysmallint as int check (value < 10);

select 9::verysmallint + 1;

The result of the addition is int, not verysmallint, which is why you
don't get an error.

From an abstract-data-type point of view, the fact that any of these
operations are even allowed without an explicit downcast is a bit
uncool: it exposes the implementation of the domain type, which one
could argue shouldn't be allowed, at least not without some notational
marker showing you know what you're doing. But the SQL committee
seems to have decided to ignore that tradition and allow auto-downcasts.
Nonetheless, when a domain type is fed to an operator that works on its
base type, it has to be clearly understood that there *is* an implied
downcast, and whatever special properties the domain may have had will
be lost. As far as the operator and its result are concerned, the
domain is just its base type.

I'm not against fixing these cases so that auto downcasts happen, I'm
just saying that it's outside the scope of what I'm going to do in
response to the current bug.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-10-21 17:49:24 Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Previous Message Kevin Grittner 2010-10-21 17:11:24 Re: Domains versus arrays versus typmods