Re: [BUGS] Bug #513: union all changes char(3) column definition
От | Peter Eisentraut |
---|---|
Тема | Re: [BUGS] Bug #513: union all changes char(3) column definition |
Дата | |
Msg-id | Pine.LNX.4.30.0111111612580.647-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: [BUGS] Bug #513: union all changes char(3) column definition (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Bug #513: union all changes char(3) column definition
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: