Re: Domains versus arrays versus typmods

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Domains versus arrays versus typmods
Дата
Msg-id 26853.1287682576@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Domains versus arrays versus typmods  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Domains versus arrays versus typmods  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Domains versus arrays versus typmods
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [JDBC] Support for JDBC setQueryTimeout, et al.