Domains and arrays and composites, oh my

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Domains and arrays and composites, oh my
Date: 2017-07-11 18:38:57
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

I started to look into allowing domains over composite types, which is
another never-implemented case that there's no very good reason not to
allow. Well, other than the argument that the SQL standard only allows
domains over "predefined" (built-in) types ... but we blew past that
restriction ages ago.

Any thought that there might be some fundamental problem with that was
soon dispelled when I noticed that we allow domains over arrays of
composite types. Ahem.

They even work, mostly. I wrote a few test cases and couldn't find
anything that failed except for attempts to insert or update multiple
subfields of the same base column; that's because process_matched_tle()
fails to look through CoerceToDomain nodes. But that turns out to be a
bug even for the simpler case of domains over arrays of scalars, which
is certainly supported. That is, given

create domain domainint4arr int4[];
create table domarrtest (testint4arr domainint4arr);

this ought to work:

insert into domarrtest (testint4arr[1], testint4arr[3]) values (11,22);

It would work with a plain-array target column, but with the domain
it fails with

ERROR: multiple assignments to same column "testint4arr"

Hence, the attached proposed patch, which fixes that oversight and
adds some relevant test cases. (I've not yet looked to see if any
documentation changes would be appropriate.)

I think this is a bug fix and should be back-patched. Any objections?

regards, tom lane

Attachment Content-Type Size
fix-multiple-assignment-to-domain-over-array.patch text/x-diff 11.6 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2017-07-11 19:24:53 Re: Multi column range partition table
Previous Message Andrew Dunstan 2017-07-11 17:58:01 Re: Arrays of domains