|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Domains and arrays and composites, oh my|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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, testint4arr) 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
|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|