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.0111221803230.766-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: > The argument here is about how much intelligence it's reasonable to > expect the system to have. It's very clearly not feasible to derive > a length limit automagically in every case. How hard should we try? I would like to know what Proprietary database #1 does with CREATE TABLE one ( a bit(6) ); INSERT INTO one VALUES ( b'101101' ); CREATE TABLE two ( b bit(4) ); INSERT INTO two VALUES ( b'0110' ); CREATE TABLE three AS SELECT a FROM one UNION SELECT b FROM two; According to SQL92, clause 9.3, the result type of the union is bit(6). However, it's not possible to store a bit(4) value into a bit(6) field. Our current solution, "bit(<nothing>)" is even worse because it has no real semantics at all (but you can store bit(<anything>) in it, interestingly). -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: