| 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: | Whole Thread | Raw Message | 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 |