Re: [BUGS] Bug #513: union all changes char(3) column definition
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] Bug #513: union all changes char(3) column definition |
Дата | |
Msg-id | 200112052104.fB5L4Ff09941@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Bug #513: union all changes char(3) column definition (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Thread added to TODO.detail. > 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 > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: