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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Diff/Patch integration -> SQL cvs clone
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Diff/Patch integration -> SQL cvs clone