From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Bug #513: union all changes char(3) column definition |
Date: | 2001-11-22 17:21:17 |
Message-ID: | Pine.LNX.4.30.0111221803230.766-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-11-23 10:20:46 | Bug #519: Bug in order by clausule |
Previous Message | Kostis | 2001-11-22 15:04:50 | UPDATE fails on large table |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-11-22 17:21:30 | Re: Diff/Patch integration -> SQL cvs clone |
Previous Message | Bruce Momjian | 2001-11-22 17:18:33 | Re: Diff/Patch integration -> SQL cvs clone |