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
peter=# create table one (a bit(4));
peter=# create table two (b bit(6));
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;
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(at)gmx(dot)net
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2001-11-11 15:40:26|
|Subject: Re: Diff/Patch integration -> SQL cvs clone|
|Previous:||From: Peter Eisentraut||Date: 2001-11-11 15:38:48|
|Subject: Re: Error on stock postgresql-tcl-7.1.3-2.i386.rpm included|
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2001-11-11 16:49:47|
|Subject: Re: Bug #513: union all changes char(3) column definition |
|Previous:||From: bruno||Date: 2001-11-11 13:30:45|
|Subject: 7.2 doc comments|