Re: Domains versus arrays versus typmods

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Oct 19, 2010 at 6:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think that what we ought to do about it is to stop exposing typelem
>> in domains' pg_type rows. If you want to subscript a domain value, you
>> should have to drill down to its base type with getBaseTypeAndTypmod,
>> which would also give you the correct typmod to apply. If we set
>> typelem to zero in domain pg_type rows, it shouldn't take too long to
>> find any places that are missing this consideration --- the breakage
>> will be obvious rather than subtle.

> I fear that this is going to degrade the performance of common cases
> as a way of debugging rare cases.

We've already accepted the cost of doing getBaseTypeAndTypmod() in a
whole lot of performance-critical parsing paths, on the off chance that
the target datatype might be a domain. It's not apparent to me that
array subscripting is so important as to deserve an exemption from that.
Especially when not doing so doesn't work.

>> Comments?

> It might be reasonable to back-patch whatever we decide on into 9.0,
> because it is so new, but I would be reluctant to go back further
> unless we have some evidence that it's bothering people. It seems to
> me that this can could have a lot of worms in it, and I fear that
> there could be several rounds of fixes, which I would rather not
> inflict on users of supposedly-stable branches.

Well, we have bug #5717 as evidence that it's bothering people ;-).
But I agree that the case for back-patching is a bit thin, especially
if it might result in any user-visible behavioral changes.

One case that I've realized is a problem is domain constraints at the
array level:

regression=# create domain orderedpair as int[2] check (value[1] < value[2]);
CREATE DOMAIN
regression=# select array[2,1]::orderedpair; -- expect failure
ERROR: value for domain orderedpair violates check constraint "orderedpair_check"
regression=# create table op (f1 orderedpair);
CREATE TABLE
regression=# insert into op values (array[1,2]);
INSERT 0 1
regression=# insert into op values (array[2,1]); -- expect failure
ERROR: value for domain orderedpair violates check constraint "orderedpair_check"
regression=# update op set f1[2] = 0; -- expect failure ... oops
UPDATE 1
regression=# select * from op;
f1
-------
{1,0}
(1 row)

The reason this fails is that the result of the ArrayRef "f1[2] := 0"
is considered to be of the domain type, so we don't recheck the
constraint. As this example demonstrates, that assumption is simply
broken. The correct implementation, I believe, is that the result
ought to be considered to be of the base type (ie, just int[]), which
would cause an implicit re-coercion to the domain type to occur during
the assignment, offering a chance to re-verify the constraint.

Right offhand I don't see a way that that sort of change can safely be
back-patched. The incorrect assumption about the ArrayRef's result
type is already baked into stored rules in existing databases.

regards, tom lane