Tom Lane writes:
> CREATE TABLE AS cannot be expected to be able to extract a suitable
> typmod from complex expressions.
I don't think that would be entirely unreasonable. The current system
drops typmods at first sight when it gets scared of them, but in many
cases it would make sense for them to propagate much further.
We've already seen a case where "no typmod" means different things in
different places for lack of a good way to keep the information. If we
ever want to allow user-defined data types to have atttypmods a solution
would be necessary.
Here's another example where the behaviour is not consistent with other
places:
peter=# create table one (a bit(4));
CREATE
peter=# create table two (b bit(6));
CREATE
peter=# insert into one values (b'1001');
INSERT 16570 1
peter=# insert into two values (b'011110');
INSERT 16571 1
peter=# select * from one union select * from two;
011110
1001
What's the data type of that? The fact is that bit without typmod makes
no sense, even less so than char without typmod.
A possible solution would be that data types can register a
typmod-resolver function, which takes two typmods and returns the typmod
to make both expressions union-compatible. For varchar(n) and varchar(m)
is would return max(m,n), for bit(n) and bit(m) it would return an error
if m<>n. (The behaviour of char() could be either of these two.)
Surely a long-term idea though...
--
Peter Eisentraut peter_e@gmx.net