Re: [BUGS] Bug #513: union all changes char(3) column definition - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [BUGS] Bug #513: union all changes char(3) column definition
Date
Msg-id Pine.LNX.4.30.0111221803230.766-100000@peter.localdomain
Whole thread Raw
In response to Re: [BUGS] Bug #513: union all changes char(3) column definition  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] Bug #513: union all changes char(3) column definition
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Diff/Patch integration -> SQL cvs clone
Next
From: Bruce Momjian
Date:
Subject: Re: Diff/Patch integration -> SQL cvs clone